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 <[email protected]>
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 <[email protected]>
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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
