Commit 72374d71 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

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
parents 27fd8085 16b52bbe

fs/kernfs/file.c

+8 −1
Original line number Diff line number Diff line
@@ -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);