Re: [PATCH 07/14] xfs: Refactor xfs_isilocked()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 16, 2021 at 05:57:12PM +0200, Jan Kara wrote:
> On Wed 16-06-21 08:47:05, Darrick J. Wong wrote:
> > On Wed, Jun 16, 2021 at 10:53:04AM +0200, Jan Kara wrote:
> > > On Wed 16-06-21 06:37:12, Christoph Hellwig wrote:
> > > > On Tue, Jun 15, 2021 at 11:17:57AM +0200, Jan Kara wrote:
> > > > > From: Pavel Reichl <preichl@xxxxxxxxxx>
> > > > > 
> > > > > Refactor xfs_isilocked() to use newly introduced __xfs_rwsem_islocked().
> > > > > __xfs_rwsem_islocked() is a helper function which encapsulates checking
> > > > > state of rw_semaphores hold by inode.
> > > > 
> > > > __xfs_rwsem_islocked doesn't seem to actually existing in any tree I
> > > > checked yet?
> > > 
> > > __xfs_rwsem_islocked is introduced by this patch so I'm not sure what are
> > > you asking about... :)
> > 
> > The sentence structure implies that __xfs_rwsem_islocked was previously
> > introduced.  You might change the commit message to read:
> > 
> > "Introduce a new __xfs_rwsem_islocked predicate to encapsulate checking
> > the state of a rw_semaphore, then refactor xfs_isilocked to use it."
> > 
> > Since it's not quite a straight copy-paste of the old code.
> 
> Ah, ok. Sure, I can rephrase the changelog (or we can just update it on
> commit if that's the only problem with this series...). Oh, now I've
> remembered I've promised you a branch to pull :) Here it is with this
> change and Christoph's Reviewed-by tags:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git hole_punch_fixes

To catch-up the list with the ext4 concall:

Dave Chinner and I have been experimenting with accepting tagged pull
requests, where the tag message is the most recent cover letter so that
the git history can capture the broader justification for the series and
the development revision history.  Signed tags would be ideal too,
though given the impossibility of meeting in person to exchange gnupg
keys (and the fact that one has to verify that the patches in the branch
more or less match what's on the list) I don't consider that an
impediment.

Also, if you want me to take this through the xfs tree then it would
make things much easier if you could base this branch off 5.13-rc4, or
something that won't cause a merge request to pull in a bunch of
unrelated upstream changes.

--D

> 
> 								Honza
> -- 
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux