Hello, > Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Nov 18, 2024 at 01:37:19AM +0900, Jeongjun Park wrote: >> Many filesystems lock inodes before calling vfs_getattr, so there is no >> data-race for inodes. However, some functions in fs/stat.c that call >> vfs_getattr do not lock inodes, so the data-race occurs. >> >> Therefore, we need to apply a patch to remove the long-standing data-race >> for inodes in some functions that do not lock inodes. > > Why do we care? Slapping even a shared lock on a _very_ hot path, with > possible considerable latency, would need more than "theoretically it's > a data race". All the functions that added lock in this patch are called only via syscall, so in most cases there will be no noticeable performance issue. And this data-race is not a problem that only occurs in theory. It is a bug that syzbot has been reporting for years. Many file systems that exist in the kernel lock inode_lock before calling vfs_getattr, so data-race does not occur, but only fs/stat.c has had a data-race for years. This alone shows that adding inode_lock to some functions is a good way to solve the problem without much performance degradation. Regards, Jeongjun Park
