Hello,
Al Viro viro@zeniv.linux.org.uk 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