On Wed, Nov 20, 2024 at 02:44:17AM +0100, Mateusz Guzik wrote: > > Pardon me, but I am unable to follow your reasoning. > > > > I suspect the argument is that the overhead of issuing a syscall is big > enough that the extra cost of taking the lock trip wont be visible, but > that's not accurate -- atomics are measurable when added to syscalls, > even on modern CPUs. Blocking is even more noticable, and the sucker can be contended. And not just by chmod() et.al. - write() will do it, for example. > Nonetheless, as an example say an inode is owned by 0:0 and is being > chowned to 1:1 and this is handled by setattr_copy. > > The ids are updated one after another: > [snip] > i_uid_update(idmap, attr, inode); > i_gid_update(idmap, attr, inode); > [/snip] > > So at least in principle it may be someone issuing getattr in parallel > will happen to spot 1:0 (as opposed to 0:0 or 1:1), which was never set > on the inode and is merely an artifact of hitting the timing. > > This would be a bug, but I don't believe this is serious enough to > justify taking the inode lock to get out of. If anything, such scenarios would be more interesting for permission checks...
