From: Louis Rilling <Louis.Rilling@kerlabs.com>
To: Joel.Becker@oracle.com
Cc: Louis.Rilling@kerlabs.com, linux-kernel@vger.kernel.org,
ocfs2-devel@oss.oracle.com
Subject: [RFC][PATCH 2/3] configfs: Silence lockdep when creating nested default groups
Date: Tue, 20 May 2008 18:33:22 +0200 [thread overview]
Message-ID: <20080520164318.701429902@kerlabs.com> (raw)
In-Reply-To: 20080520163320.025971210@kerlabs.com
[-- Attachment #1: configfs-silence-lockdep-with-default-group-creation.patch --]
[-- Type: text/plain, Size: 2420 bytes --]
When default groups are nested, lockdep raises a warning since it sees a
lock recursion of class I_MUTEX_CHILD in populate_groups().
However, this lock recursion is just a variant of the I_MUTEX_PARENT ->
I_MUTEX_CHILD dependency, which is ok in the VFS, and is already checked when
creating the first level of default groups.
This patch silences lockdep with nested default groups, by hiding the mutex
locks of populate_groups() from lockdep when the considered config_group is
itself a default group. The mutex is not hidden for a non-default group, so that
the lock dependency remains checked, in case things change in some future.
Signed-off-by: Louis Rilling <Louis.Rilling@kerlabs.com>
---
fs/configfs/dir.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: b/fs/configfs/dir.c
===================================================================
--- a/fs/configfs/dir.c 2008-05-20 18:19:35.000000000 +0200
+++ b/fs/configfs/dir.c 2008-05-20 18:19:41.000000000 +0200
@@ -535,6 +535,8 @@ static int populate_groups(struct config
int i;
if (group->default_groups) {
+ struct configfs_dirent *sd = dentry->d_fsdata;
+ int turn_lockdep_off = (sd->s_type & CONFIGFS_USET_DEFAULT);
/*
* FYI, we're faking mkdir here
* I'm not sure we need this semaphore, as we're called
@@ -544,7 +546,18 @@ static int populate_groups(struct config
* That said, taking our i_mutex is closer to mkdir
* emulation, and shouldn't hurt.
*/
+ /* For a default group, we hide this mutex from lockdep since:
+ * 1/ This is a case of I_MUTEX_PARENT -> I_MUTEX_CHILD
+ * dependency;
+ * 2/ This dependency was already checked when creating the
+ * parent of this group;
+ * 3/ Lockdep does not handle such safe recursion.
+ */
+ if (turn_lockdep_off)
+ lockdep_off();
mutex_lock_nested(&dentry->d_inode->i_mutex, I_MUTEX_CHILD);
+ if (turn_lockdep_off)
+ lockdep_on();
for (i = 0; group->default_groups[i]; i++) {
new_group = group->default_groups[i];
@@ -554,7 +567,11 @@ static int populate_groups(struct config
break;
}
+ if (turn_lockdep_off)
+ lockdep_off();
mutex_unlock(&dentry->d_inode->i_mutex);
+ if (turn_lockdep_off)
+ lockdep_on();
}
if (ret)
--
Dr Louis Rilling Kerlabs
Skype: louis.rilling Batiment Germanium
Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes
http://www.kerlabs.com/ 35700 Rennes
next prev parent reply other threads:[~2008-05-20 16:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 16:33 [RFC][PATCH 0/3] configfs: Make nested default groups lockdep-friendly Louis Rilling
2008-05-20 16:33 ` [RFC][PATCH 1/3] configfs: set CONFIGFS_USET_DEFAULT earlier in configfs_attach_group() Louis Rilling
2008-05-20 16:33 ` Louis Rilling [this message]
2008-05-20 16:33 ` [RFC][PATCH 3/3] configfs: Silence lockdep when destroying default groups Louis Rilling
2008-05-20 16:58 ` [RFC][PATCH 0/3] configfs: Make nested default groups lockdep-friendly Arjan van de Ven
2008-05-20 17:08 ` Louis Rilling
2008-05-20 21:56 ` Joel Becker
2008-05-20 22:13 ` Arjan van de Ven
2008-05-20 22:27 ` Joel Becker
2008-05-20 22:35 ` Arjan van de Ven
2008-05-20 23:51 ` Joel Becker
2008-05-21 9:20 ` Peter Zijlstra
2008-05-21 9:23 ` Peter Zijlstra
2008-05-21 10:25 ` Louis Rilling
2008-05-21 10:59 ` Peter Zijlstra
2008-05-21 12:54 ` Louis Rilling
2008-05-21 22:09 ` Joel Becker
2008-05-21 8:13 ` Louis Rilling
2008-05-20 21:41 ` [Ocfs2-devel] " Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080520164318.701429902@kerlabs.com \
--to=louis.rilling@kerlabs.com \
--cc=Joel.Becker@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox