On Thu, Jun 17, 2021 at 09:29:20AM -0700, Darrick J. Wong wrote: > 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. Oh, and also: Please send pull requests as a new thread tagged '[GIT PULL]' so the requests don't get buried in a patch reply thread. --D > --D > > > > > Honza > > -- > > Jan Kara <jack@xxxxxxxx> > > SUSE Labs, CR
