linux-kernel - [PATCH] sysfs: differentiate between locking links and non-links

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2010 12:09:33 +1100
From:	Neil Brown <neilb@...e.de>
To:	Eric W "." Biederman <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] sysfs: differentiate  between locking links and non-links

Hi,
 I've just spent a while sorting out some lockdep complaints triggered
 by the recent addition of the "s_active" lockdep annotation in sysfs
  (commit 846f99749ab68bbc7f75c74fec305de675b1a1bf)

 Some of them are genuine and I have submitted a fix for those.
 Some are, I think, debatable and I get to that is a minute.  I've
 submitted a fix for them anyway.
 But some are to my mind clearly bogus and I'm hoping that can be
 fixed by the change below (or similar).
 The 'bogus' ones are triggered by writing to a sysfs attribute file
 for which the handler tries to delete a symlink from sysfs.
 This appears to be a recursion on s_active as s_active is held while
 the handler runs and is again needed to effect the delete.  However
 as the thing being deleted is a symlink, it is very clearly a
 different object to the thing triggering the delete, so there is no
 real loop.

 The following patch splits the lockdep context in two - one for
 symlink and one for everything else.  This removes the apparent loop.
 (An example report can be seen in
     http://bugzilla.kernel.org/show_bug.cgi?id=15142).

 The "debatable" dependency loops happen when writing to one attribute
 causes a different attribute to be deleted.  In my (md) case this can
 actually cause a deadlock as both the attributes take the same lock
 while the handler is running.  This is because deleting the attribute
 will block until the all accesses of that attribute have completed (I
 think).
 However it should be possible to delete a name from sysfs while there
 are still accesses pending (it works for normal files!!).  So if
 sysfs could be changed to simply unlink the file and leave deletion to
 happen when the refcount become zero it would certainly make my life
 a lot easier, and allow the removal of some ugly code from md.c.
 I don't know sysfs well enough to suggest a patch though.

Thanks,
NeilBrown

commit 2e502cfe444b68f6ef6b8b2abe83b6112564095b
Author: NeilBrown <neilb@...e.de>
Date:   Wed Feb 10 09:43:45 2010 +1100

    sysfs: differentiate  between locking links and non-links for sysfs

    symlinks and non-symlink is sysfs are very different.
    A symlink can never be locked (active) while an attribute
    modification routine is running.  So removing symlink from an
    attribute 'store' routine should be permitted without any lockdep
    warnings.

    So split the lockdep context for 's_active' in two, one for symlinks
    and other for everything else.

    Signed-off-by: NeilBrown <neilb@...e.de>

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 699f371..e6eeaf6 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -354,7 +354,10 @@ struct sysfs_dirent *sysfs_new_dirent(const char *name, umode_t mode, int type)

 	atomic_set(&sd->s_count, 1);
 	atomic_set(&sd->s_active, 0);
-	sysfs_dirent_init_lockdep(sd);
+	if (type & SYSFS_KOBJ_LINK)
+		sysfs_dirent_init_lockdep(sd, "link");
+	else
+		sysfs_dirent_init_lockdep(sd, "non_link");

 	sd->s_name = name;
 	sd->s_mode = mode;
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index cdd9377..a83a02b 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -89,11 +89,11 @@ static inline unsigned int sysfs_type(struct sysfs_dirent *sd)
 }

 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-#define sysfs_dirent_init_lockdep(sd)				\
+#define sysfs_dirent_init_lockdep(sd, type)			\
 do {								\
 	static struct lock_class_key __key;			\
 								\
-	lockdep_init_map(&sd->dep_map, "s_active", &__key, 0);	\
+	lockdep_init_map(&sd->dep_map, "s_active_" type, &__key, 0);	\
 } while(0)
 #else
 #define sysfs_dirent_init_lockdep(sd) do {} while(0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/