On Sun, 6 Aug 2023 at 06:26, Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxxxxx: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@xxxxxxxxxxxxxxxxxxx:pub/scm/linux/kernel/git/vfs/vfs tags/v6.5-rc5.vfs.fixes
I had actually planned on just waiting for the 6.6 merge window, but
then you made this _so_ easy for me that I ended up taking these
things right now.
The timing may not be entirely right, but I'm very comfortable with
the "get rid of '->iterate' op" change since it (a) would clearly fail
the build on a missed conversion and (b) doesn't touch any core
filesystems anyway.
And now that file_needs_f_pos_lock() does look better, and as you say
in teh commit, makes it clearer why that locking rule exists.
Linus
Linus
