| Message ID | 20240111212424.3572189-1-willy@infradead.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove the XFS mrlock | expand |
On Thu, Jan 11, 2024 at 09:24:21PM +0000, Matthew Wilcox (Oracle) wrote: > XFS has an mrlock wrapper around the rwsem which adds only the > functionality of knowing whether the rwsem is currently held in read > or write mode. Both regular rwsems and rt-rwsems know this, they just > don't expose it as an API. By adding that, we can remove the XFS mrlock > as well as improving the debug assertions for the mmap_lock when lockdep > is disabled. > > I have an ack on the first patch from Peter, so I would like to see this > merged through the XFS tree since most of what it touches is XFS. With the minor nits that have already been noticed fix up, the whole series looks good to me. Reviewed-by: Dave Chinner <dchinner@redhat.com>
On Thu, Jan 11, 2024 at 09:24:21PM +0000, Matthew Wilcox (Oracle) wrote: > XFS has an mrlock wrapper around the rwsem which adds only the > functionality of knowing whether the rwsem is currently held in read > or write mode. Both regular rwsems and rt-rwsems know this, they just > don't expose it as an API. By adding that, we can remove the XFS mrlock > as well as improving the debug assertions for the mmap_lock when lockdep > is disabled. > > I have an ack on the first patch from Peter, so I would like to see this > merged through the XFS tree since most of what it touches is XFS. What needs to happen to get these picked up to not miss the next merge window?
On Wed, Feb 14, 2024 at 10:05:10PM +0000, Matthew Wilcox wrote: > On Thu, Jan 11, 2024 at 09:24:21PM +0000, Matthew Wilcox (Oracle) wrote: > > XFS has an mrlock wrapper around the rwsem which adds only the > > functionality of knowing whether the rwsem is currently held in read > > or write mode. Both regular rwsems and rt-rwsems know this, they just > > don't expose it as an API. By adding that, we can remove the XFS mrlock > > as well as improving the debug assertions for the mmap_lock when lockdep > > is disabled. > > > > I have an ack on the first patch from Peter, so I would like to see this > > merged through the XFS tree since most of what it touches is XFS. > > What needs to happen to get these picked up to not miss the next merge > window? Rebase against xfs-linux for-next, then send Chandan a pull request. That would have gotten done this morning, only now everything's on hold again while we wait for the mm maintainers to get around to reviewing the patches in the xfile diet v3 series: https://lore.kernel.org/linux-xfs/87frxva65g.fsf@debian-BULLSEYE-live-builder-AMD64/T/#m99f2f7e1fb221c4d7f5a00f249119d570ab70fce Yes I know you already reviewed all of them (again, thank you!) but apparently your RVB tag is not good enough for the very high standards of the kernel community. In the mean time, the only thing we can do is wait patiently and hope that one of the maintainers can free up enough time to take a look. </sarcasm> --D
On Wed, Feb 14, 2024 at 10:05:10 PM +0000, Matthew Wilcox wrote: > On Thu, Jan 11, 2024 at 09:24:21PM +0000, Matthew Wilcox (Oracle) wrote: >> XFS has an mrlock wrapper around the rwsem which adds only the >> functionality of knowing whether the rwsem is currently held in read >> or write mode. Both regular rwsems and rt-rwsems know this, they just >> don't expose it as an API. By adding that, we can remove the XFS mrlock >> as well as improving the debug assertions for the mmap_lock when lockdep >> is disabled. >> >> I have an ack on the first patch from Peter, so I would like to see this >> merged through the XFS tree since most of what it touches is XFS. > > What needs to happen to get these picked up to not miss the next merge > window? Sorry, I missed this patchset. I tried applying this patchset on top of XFS' current for-next branch. But it failed due to merge conflicts. I would suggest that you should wait until the "shmem patches" impasse gets resolved and for-next branch becomes stable. I will respond to this mail as to when you can rebase your patchset on for-next and either send a pull request or post the rebased version of the patchset to the mailing list.
On Wed, Feb 14, 2024 at 10:05:10 PM +0000, Matthew Wilcox wrote: > On Thu, Jan 11, 2024 at 09:24:21PM +0000, Matthew Wilcox (Oracle) wrote: >> XFS has an mrlock wrapper around the rwsem which adds only the >> functionality of knowing whether the rwsem is currently held in read >> or write mode. Both regular rwsems and rt-rwsems know this, they just >> don't expose it as an API. By adding that, we can remove the XFS mrlock >> as well as improving the debug assertions for the mmap_lock when lockdep >> is disabled. >> >> I have an ack on the first patch from Peter, so I would like to see this >> merged through the XFS tree since most of what it touches is XFS. > > What needs to happen to get these picked up to not miss the next merge > window? Matthew, I have updated XFS' for-next branch. The HEAD commit is now 49c379d3a72ab86aafeafebe6b43577acb1ef359 ("xfs: use kvfree for buf in xfs_ioc_getbmap"). Pleae rebase your patchset on top of for-next and either post the rebased patchset or you can send me a pull request.