Re: [PATCH] file: always lock position

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

 



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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux