Skip to content

Commit 72374d7

Browse files
committed
Merge tag 'pull-sysfs-annotation-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull sysfs fix from Al Viro: "Get rid of lockdep false positives around sysfs/overlayfs syzbot has uncovered a class of lockdep false positives for setups with sysfs being one of the backing layers in overlayfs. The root cause is that of->mutex allocated when opening a sysfs file read-only (which overlayfs might do) is confused with of->mutex of a file opened writable (held in write to sysfs file, which overlayfs won't do). Assigning them separate lockdep classes fixes that bunch and it's obviously safe" * tag 'pull-sysfs-annotation-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: kernfs: annotate different lockdep class for of->mutex of writable files
2 parents 27fd808 + 16b52bb commit 72374d7

File tree

1 file changed

+8
-1
lines changed

1 file changed

+8
-1
lines changed

fs/kernfs/file.c

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -636,11 +636,18 @@ static int kernfs_fop_open(struct inode *inode, struct file *file)
636636
* each file a separate locking class. Let's differentiate on
637637
* whether the file has mmap or not for now.
638638
*
639-
* Both paths of the branch look the same. They're supposed to
639+
* For similar reasons, writable and readonly files are given different
640+
* lockdep key, because the writable file /sys/power/resume may call vfs
641+
* lookup helpers for arbitrary paths and readonly files can be read by
642+
* overlayfs from vfs helpers when sysfs is a lower layer of overalyfs.
643+
*
644+
* All three cases look the same. They're supposed to
640645
* look that way and give @of->mutex different static lockdep keys.
641646
*/
642647
if (has_mmap)
643648
mutex_init(&of->mutex);
649+
else if (file->f_mode & FMODE_WRITE)
650+
mutex_init(&of->mutex);
644651
else
645652
mutex_init(&of->mutex);
646653

0 commit comments

Comments
 (0)