aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2009-10-05 10:31:37 -0400
committerFrederic Weisbecker <fweisbec@gmail.com>2009-10-05 10:31:37 -0400
commit48f6ba5e691948caba2e7bc362153fb28e4f1e09 (patch)
tree318e755ec8c3664b1276a5a87f455b8dc37c3862
parent193be0ee17dd7ea309ddab1093da17e5924d7f36 (diff)
kill-the-bkl/reiserfs: fix reiserfs lock to cpu_add_remove_lock dependency
While creating the reiserfs workqueue during the journal initialization, we are holding the reiserfs lock, but create_workqueue() also holds the cpu_add_remove_lock, creating then the following dependency: - reiserfs lock -> cpu_add_remove_lock But we also have the following existing dependencies: - mm->mmap_sem -> reiserfs lock - cpu_add_remove_lock -> cpu_hotplug.lock -> slub_lock -> sysfs_mutex The merged dependency chain then becomes: - mm->mmap_sem -> reiserfs lock -> cpu_add_remove_lock -> cpu_hotplug.lock -> slub_lock -> sysfs_mutex But when we fill a dir entry in sysfs_readir(), we are holding the sysfs_mutex and we also might fault while copying the directory entry to the user, leading to the following dependency: - sysfs_mutex -> mm->mmap_sem The end result is then a lock inversion between sysfs_mutex and mm->mmap_sem, as reported in the following lockdep warning: [ INFO: possible circular locking dependency detected ] 2.6.31-07095-g25a3912 #4 ------------------------------------------------------- udevadm/790 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<c1098942>] might_fault+0x72/0xc0 but task is already holding lock: (sysfs_mutex){+.+.+.}, at: [<c110813c>] sysfs_readdir+0x7c/0x260 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #5 (sysfs_mutex){+.+.+.}: [...] -> #4 (slub_lock){+++++.}: [...] -> #3 (cpu_hotplug.lock){+.+.+.}: [...] -> #2 (cpu_add_remove_lock){+.+.+.}: [...] -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [...] -> #0 (&mm->mmap_sem){++++++}: [...] This can be fixed by relaxing the reiserfs lock while creating the workqueue. This is fine to relax the lock here, we just keep it around to pass through reiserfs lock checks and for paranoid reasons. Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Tested-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Alexander Beregalov <a.beregalov@gmail.com> Cc: Laurent Riffard <laurent.riffard@free.fr>
-rw-r--r--fs/reiserfs/journal.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
index 04e3c42a085f..2f8a7e7b8dab 100644
--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -2933,8 +2933,11 @@ int journal_init(struct super_block *sb, const char *j_dev_name,
2933 } 2933 }
2934 2934
2935 reiserfs_mounted_fs_count++; 2935 reiserfs_mounted_fs_count++;
2936 if (reiserfs_mounted_fs_count <= 1) 2936 if (reiserfs_mounted_fs_count <= 1) {
2937 reiserfs_write_unlock(sb);
2937 commit_wq = create_workqueue("reiserfs"); 2938 commit_wq = create_workqueue("reiserfs");
2939 reiserfs_write_lock(sb);
2940 }
2938 2941
2939 INIT_DELAYED_WORK(&journal->j_work, flush_async_commits); 2942 INIT_DELAYED_WORK(&journal->j_work, flush_async_commits);
2940 journal->j_work_sb = sb; 2943 journal->j_work_sb = sb;