From: Arjan van de Ven <arjan@infradead.org>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, john.ronciak@intel.com,
jesse.brandeburg@intel.com, trond.myklebust@fys.uio.no
Subject: Re: e1000 vs nfs/net circular locking report
Date: Tue, 11 Jul 2006 13:53:37 +0200 [thread overview]
Message-ID: <1152618818.3128.36.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <20060711115143.GB4113@suse.de>
On Tue, 2006-07-11 at 13:51 +0200, Jens Axboe wrote:
> Hi,
>
> Upon cd'ing to an nfs mounted directory, I received this report. It's
> perfectly reproducible.
this patch (about to be merged in mainline) should fix it
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: fix false positives by giving sysfs inodes their own lock class
sysfs has a different i_mutex lock order behavior for i_mutex than the other
filesystems; sysfs i_mutex is called in many places with subsystem locks
held. At the same time, many of the VFS locking rules do not apply to sysfs
at all (cross directory rename for example). To untangle this mess (which
gives false positives in lockdep), we're giving sysfs inodes their own class
for i_mutex.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Index: linux-2.6.18-rc1/fs/sysfs/inode.c
===================================================================
--- linux-2.6.18-rc1.orig/fs/sysfs/inode.c
+++ linux-2.6.18-rc1/fs/sysfs/inode.c
@@ -109,6 +109,17 @@ static inline void set_inode_attr(struct
inode->i_ctime = iattr->ia_ctime;
}
+
+/*
+ * sysfs has a different i_mutex lock order behavior for i_mutex than other
+ * filesystems; sysfs i_mutex is called in many places with subsystem locks
+ * held. At the same time, many of the VFS locking rules do not apply to
+ * sysfs at all (cross directory rename for example). To untangle this mess
+ * (which gives false positives in lockdep), we're giving sysfs inodes their
+ * own class for i_mutex.
+ */
+static struct lock_class_key sysfs_inode_imutex_key;
+
struct inode * sysfs_new_inode(mode_t mode, struct sysfs_dirent * sd)
{
struct inode * inode = new_inode(sysfs_sb);
@@ -118,6 +129,7 @@ struct inode * sysfs_new_inode(mode_t mo
inode->i_mapping->a_ops = &sysfs_aops;
inode->i_mapping->backing_dev_info = &sysfs_backing_dev_info;
inode->i_op = &sysfs_inode_operations;
+ lockdep_set_class(&inode->i_mutex, &sysfs_inode_imutex_key);
if (sd->s_iattr) {
/* sysfs_dirent has non-default attributes
prev parent reply other threads:[~2006-07-11 11:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 11:51 Jens Axboe
2006-07-11 11:53 ` Arjan van de Ven [this message]
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=1152618818.3128.36.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=axboe@suse.de \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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
all inboxes | Powered by JetHome®