Get rid of lockdep false positives around sysfs/overlayfs
-----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQQqUNBr3gm4hGXdBJlZ7Krx/gZQ6wUCZhu2kwAKCRBZ7Krx/gZQ 62gzAP9eeADy6rQkzgWJ8d8sKzGfmd0nup9WlCOxZSR0XojTXwEAnue47dn7PlMx wQY0joZ0V5FO8PNTEbWc2P/dSQrANgc= =MshW -----END PGP SIGNATURE----- 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
This commit is contained in:
commit
72374d71c3
@ -636,11 +636,18 @@ static int kernfs_fop_open(struct inode *inode, struct file *file)
|
||||
* each file a separate locking class. Let's differentiate on
|
||||
* whether the file has mmap or not for now.
|
||||
*
|
||||
* Both paths of the branch look the same. They're supposed to
|
||||
* For similar reasons, writable and readonly files are given different
|
||||
* lockdep key, because the writable file /sys/power/resume may call vfs
|
||||
* lookup helpers for arbitrary paths and readonly files can be read by
|
||||
* overlayfs from vfs helpers when sysfs is a lower layer of overalyfs.
|
||||
*
|
||||
* All three cases look the same. They're supposed to
|
||||
* look that way and give @of->mutex different static lockdep keys.
|
||||
*/
|
||||
if (has_mmap)
|
||||
mutex_init(&of->mutex);
|
||||
else if (file->f_mode & FMODE_WRITE)
|
||||
mutex_init(&of->mutex);
|
||||
else
|
||||
mutex_init(&of->mutex);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user