On Wed, Feb 28, 2024 at 11:27:05PM -0800, Linus Torvalds wrote: > On Wed, 28 Feb 2024 at 23:20, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > - take the lock exclusively if O_APPEND or if it *looks* like you > > might extend the file size. > > > > - otherwise, take the shared lock, and THEN RE-CHECK. The file size > > might have changed, so now you need to double-check that you're really > > not going to extend the size of the file, and if you are, you need to > > go back and take the inode lock exclusively after all. > > Same goes for the suid/sgid checks. You need to take the inode lock > shared to even have the i_mode be stable, and at that point you might > decide "oh, I need to clear suid/sgid after all" and have to go drop > the lock and retake it for exclusive access after all. Do we though? Yes i_mode can change mid write, but if userspace issues a chmod() while we're in a write() - the end result has to be consistent with either "chmod(); write();" or 'write(); chmod();"; meaning as long as there's been a barrier in the syscall path so that we can't have seen a value of i_mode from before the chmod returned we're good.
