Re: [PATCH] file: always lock position

[Christian Brauner <brauner@kernel.org>]

On Sun, Aug 06, 2023 at 08:10:40AM +0200, Christian Brauner wrote:
> > Yes, some filesystems then still get the inode lock in write mode, but
> > now it's the filesystem itself that wraps its own iterator, rather
> > than cause pain for the callers.
> 
> And, btrfs already does this in some cases where it first upgrades from
> shared to non-shared and then downgrades again before returning in
> btrfs_real_readdir(). So it's not like this isn't already happening.
> 
> > 
> > So no more "Do you have an ->iterate() _or_ ->iterate_shared()
> > function?" and associated "I need to do locking differently"
> > nastiness. Only odd filesystems that never got the memo on "don't use
> > .iterate".
> 
> Ack. It's not pretty but that hasn't stopped us before and it's less
> ugly than double inode methods which pass exactly the same parameters. I
> think removing the double methods is good and I see no problem in
> shaming filesystems that didn't manage to convert properly in the last 7
> years.
> 
> And let's please not get stuck on incoming pinky promises that everyone
> will have converted before the next 7 years are over. I'd prefer to see
> the iop wiped and leave the ugliness to the individual filesystems rn.

We got sent a fix for a wrong check for O_TMPFILE during RESOLVE_CACHED
lookup which I've put on vfs.fixes yesterday:

git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/v6.5-rc5.vfs.resolve_cached.fix

But in case you planned on applying this directly instead of waiting for
next cycle I've added your two appended patches on top of it and my
earlier patch for massaging the file_needs_f_pos_lock() check that
triggered this whole thing:

git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/v6.5-rc5.vfs.fixes