Re: [PATCH] fs: prevent data-race due to missing inode_lock when calling vfs_getattr

[Al Viro <viro@zeniv.linux.org.uk>]

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