[PATCH 2/2] configfs: give the root inode its own lockdep class

[Slawomir Stepien <sst@poczta.fm>]

configfs_depend_item_unlocked() is meant to be called from configfs
callbacks, where VFS already holds directory inode locks and configfs
holds the subsystem's su_mutex. When the target item lives in another
subsystem, it additionally locks the configfs root inode so that the
target subsystem cannot be unregistered underneath it.

The root inode shares the &sb->s_type->i_mutex_key lockdep class with
every user-created configfs directory, so lockdep cannot tell it apart
from the directory inode locks taken by mkdir, rmdir and symlink. Any
lock held by the depend caller therefore looks like it nests both
inside and outside "the" configfs inode lock. f_tcm's usbg_make_tpg(),
which depends on a gadget function item from the target subsystem's
mkdir callback, triggers this in two ways:

  target su_mutex -> root inode (depend), while
  rmdir under target/: directory inode -> target su_mutex

  tpg_instances_lock -> root inode (depend), while
  mkdir functions/tcm.N: directory inode -> gadget su_mutex ->
    func_lock -> tpg_instances_lock (tcm_alloc_inst())

Neither is a real deadlock, because no holder of the root inode lock
waits for su_mutex, tpg_instances_lock or a directory inode lock held
by a depend caller:

 - configfs_depend_item() and configfs_depend_item_unlocked() only look
   up the subsystem and scan the tree under configfs_dirent_lock, a
   spinlock.
 - Lookup and readdir in the configfs root only take
   configfs_dirent_lock. mkdir and symlink in the root fail with
   -EPERM before any other lock is taken, and configfs_rmdir() of a
   subsystem directory never gets as far as taking su_mutex.
 - configfs_register_subsystem() only locks the inodes of the new
   subsystem directory it is creating, which nobody else can hold yet.
 - configfs_unregister_subsystem() does wait for the subsystem
   directory's inode lock, but it only runs from the subsystem module's
   exit path. Every mkdir and rmdir in that subsystem holds a reference
   on the module, so none of them can be in progress at that point.

Put the root inode's i_rwsem into its own lock class so that lockdep
stops aliasing it with ordinary directory inodes. Splitting a class
cannot create new lockdep cycles, and real dependencies on the root
inode are still tracked under the new class. This is an annotation
only: without CONFIG_LOCKDEP the key is empty and lockdep_set_class()
compiles away.

Fixes: d79d75b5c518 ("fs: configfs: Add unlocked version of configfs_depend_item()")
Reported-by: syzbot+b3410eb576b568216ae5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b3410eb576b568216ae5
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
---
 fs/configfs/mount.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
index d8cac1cbf3bd..f5e9b98c1315 100644
--- a/fs/configfs/mount.c
+++ b/fs/configfs/mount.c
@@ -15,11 +15,19 @@
 #include <linux/fs_context.h>
 #include <linux/pagemap.h>
 #include <linux/init.h>
+#include <linux/lockdep.h>
 #include <linux/slab.h>
 
 #include <linux/configfs.h>
 #include "configfs_internal.h"
 
+/*
+ * configfs_depend_item_unlocked() locks the root inode while the caller holds
+ * su_mutex and other locks from a configfs callback; nothing taken under the
+ * root inode lock depends on those, so keep it out of the directory class.
+ */
+static struct lock_class_key configfs_root_inode_class;
+
 static struct vfsmount *configfs_mount = NULL;
 struct kmem_cache *configfs_dir_cachep;
 static int configfs_mnt_count = 0;
@@ -74,6 +82,7 @@ static int configfs_fill_super(struct super_block *sb, struct fs_context *fc)
 	if (inode) {
 		inode->i_op = &configfs_root_inode_operations;
 		inode->i_fop = &configfs_dir_operations;
+		lockdep_set_class(&inode->i_rwsem, &configfs_root_inode_class);
 		/* directory inodes start off with i_nlink == 2 (for "." entry) */
 		inc_nlink(inode);
 	} else {
-- 
2.56.0