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...