s_active is released by the thread doing the final sysfs_put() which
can be different from the thread which did sysfs_deactivate().  Make
lockdep think that s_active is unlocked immediately after it's write
locked.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---

Greg, this patch fixes lockdep error reported by Cornelia.  Please add
this to the patch series.  Andrew, this is the same one you took
earlier only with comments added.

Thanks.

 fs/sysfs/dir.c   |    7 ++++++-
 fs/sysfs/sysfs.h |    5 +++++
 2 files changed, 11 insertions(+), 1 deletion(-)

Index: work/fs/sysfs/dir.c
===================================================================
--- work.orig/fs/sysfs/dir.c
+++ work/fs/sysfs/dir.c
@@ -25,8 +25,13 @@ void release_sysfs_dirent(struct sysfs_d
        /* If @sd is being released after deletion, s_active is write
         * locked.  If @sd is cursor for directory walk or being
         * released prematurely, s_active has no reader or writer.
+        *
+        * sysfs_deactivate() lies to lockdep that s_active is
+        * unlocked immediately.  Lie one more time to cover the
+        * previous lie.
         */
-       down_write_trylock(&sd->s_active);
+       if (!down_write_trylock(&sd->s_active))
+               rwsem_acquire(&sd->s_active.dep_map, 0, 0, _RET_IP_);
        up_write(&sd->s_active);
 
        if (sd->s_type & SYSFS_KOBJ_LINK)
Index: work/fs/sysfs/sysfs.h
===================================================================
--- work.orig/fs/sysfs/sysfs.h
+++ work/fs/sysfs/sysfs.h
@@ -171,6 +171,11 @@ static inline void sysfs_put_active_two(
 static inline void sysfs_deactivate(struct sysfs_dirent *sd)
 {
        down_write(&sd->s_active);
+
+       /* s_active will be unlocked by the thread doing the final put
+        * on @sd.  Lie to lockdep.
+        */
+       rwsem_release(&sd->s_active.dep_map, 1, _RET_IP_);
 }
 
 static inline int sysfs_is_shadowed_inode(struct inode *inode)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to