tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

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

Linus Torvalds 72374d71 27fd8085

+8 -1
+8 -1
fs/kernfs/file.c
··· 636 636 * each file a separate locking class. Let's differentiate on 637 637 * whether the file has mmap or not for now. 638 638 * 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 640 645 * look that way and give @of->mutex different static lockdep keys. 641 646 */ 642 647 if (has_mmap) 648 + mutex_init(&of->mutex); 649 + else if (file->f_mode & FMODE_WRITE) 643 650 mutex_init(&of->mutex); 644 651 else 645 652 mutex_init(&of->mutex);