[PATCH] sysfs: use different lockdep subclass for s_active deactivation

From: Tejun Heo
Date: Thu Apr 26 2007 - 10:51:12 EST

A sysfs node can delete other sysfs files when accessed. This results
in recursive s_active locking - read lock for file access, down lock
of the vicitim for deactivation. Tell lockdep that it's okay.

Signed-off-by: Tejun Heo <htejun@xxxxxxxxx>
Miles, please test this patch. It should remove the lockdep warning.
Fixes for the other two problems will soon follow.

Greg, Andrew, after all the fixes are verified, I'll merge the fixes
into the original patches and resend all the sysfs updates in better
shape. Sorry about all the trouble.


diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 8f7b65e..4a418bd 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -60,7 +60,8 @@ void release_sysfs_dirent(struct sysfs_dirent * sd)
* previous lie.
if (!down_write_trylock(&sd->s_active))
- rwsem_acquire(&sd->s_active.dep_map, 0, 0, _RET_IP_);
+ rwsem_acquire(&sd->s_active.dep_map,

diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 4ed6f77..add2725 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -41,6 +41,17 @@ struct sysfs_dirent {
atomic_t s_event;

+ * A sysfs file which deletes another file when written to need to
+ * write lock the s_active of the victim while its s_active is read
+ * locked for the write operation. Tell lockdep that this is okay.
+ */
+enum sysfs_s_active_class
+ SYSFS_S_ACTIVE_NORMAL, /* file r/w access, etc - default */
+ SYSFS_S_ACTIVE_DEACTIVATE, /* file deactivation */
extern struct vfsmount * sysfs_mount;
extern struct kmem_cache *sysfs_dir_cachep;

@@ -172,7 +183,7 @@ static inline void sysfs_put_active_two(struct sysfs_dirent *sd)
static inline void sysfs_deactivate(struct sysfs_dirent *sd)
- down_write(&sd->s_active);
+ down_write_nested(&sd->s_active, SYSFS_S_ACTIVE_DEACTIVATE);

/* s_active will be unlocked by the thread doing the final put
* on @sd. Lie to lockdep.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/