Files
kernel-tenderloin-3.0/include/linux
Roland Dreier 51ee049e77 vfs: add lockdep annotation to s_vfs_rename_key for ecryptfs
>  =============================================
 >  [ INFO: possible recursive locking detected ]
 >  2.6.31-2-generic #14~rbd3
 >  ---------------------------------------------
 >  firefox-3.5/4162 is trying to acquire lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >
 >  but task is already holding lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >
 >  other info that might help us debug this:
 >  3 locks held by firefox-3.5/4162:
 >   #0:  (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >   #1:  (&sb->s_type->i_mutex_key#11/1){+.+.+.}, at: [<ffffffff81139d5a>] lock_rename+0x6a/0xf0
 >   #2:  (&sb->s_type->i_mutex_key#11/2){+.+.+.}, at: [<ffffffff81139d6f>] lock_rename+0x7f/0xf0
 >
 >  stack backtrace:
 >  Pid: 4162, comm: firefox-3.5 Tainted: G         C 2.6.31-2-generic #14~rbd3
 >  Call Trace:
 >   [<ffffffff8108ae74>] print_deadlock_bug+0xf4/0x100
 >   [<ffffffff8108ce26>] validate_chain+0x4c6/0x750
 >   [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
 >   [<ffffffff8108d585>] lock_acquire+0xa5/0x150
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff8120eaf9>] ? ecryptfs_rename+0x99/0x170
 >   [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60
 >   [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >   [<ffffffff8120eb2a>] ecryptfs_rename+0xca/0x170
 >   [<ffffffff81139a9e>] vfs_rename_dir+0x13e/0x160
 >   [<ffffffff8113ac7e>] vfs_rename+0xee/0x290
 >   [<ffffffff8113c212>] ? __lookup_hash+0x102/0x160
 >   [<ffffffff8113d512>] sys_renameat+0x252/0x280
 >   [<ffffffff81133eb4>] ? cp_new_stat+0xe4/0x100
 >   [<ffffffff8101316a>] ? sysret_check+0x2e/0x69
 >   [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190
 >   [<ffffffff8113d55b>] sys_rename+0x1b/0x20
 >   [<ffffffff81013132>] system_call_fastpath+0x16/0x1b

The trace above is totally reproducible by doing a cross-directory
rename on an ecryptfs directory.

The issue seems to be that sys_renameat() does lock_rename() then calls
into the filesystem; if the filesystem is ecryptfs, then
ecryptfs_rename() again does lock_rename() on the lower filesystem, and
lockdep can't tell that the two s_vfs_rename_mutexes are different.  It
seems an annotation like the following is sufficient to fix this (it
does get rid of the lockdep trace in my simple tests); however I would
like to make sure I'm not misunderstanding the locking, hence the CC
list...

Signed-off-by: Roland Dreier <rdreier@cisco.com>
Cc: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-05-21 18:31:22 -04:00
..
2010-05-17 22:39:48 -07:00
2010-05-03 08:33:00 -04:00
2010-04-23 14:43:45 -04:00
2010-03-12 15:53:10 -08:00
2010-05-14 17:08:01 -04:00
2009-12-16 07:20:13 -08:00
2010-05-19 13:38:54 -04:00
2010-04-25 08:54:42 +02:00
2010-03-12 15:52:32 -08:00
2010-02-05 07:35:05 -08:00
2010-05-10 16:08:01 -07:00
2010-05-21 19:30:44 +02:00
2009-12-15 08:53:33 -08:00
2009-12-23 13:33:54 +01:00
2010-05-18 16:19:30 +10:00
2010-03-16 08:55:32 +01:00
2010-05-21 09:34:29 -07:00
2010-02-09 11:13:56 +01:00
2010-03-07 22:17:09 +01:00
2010-03-02 12:23:42 +01:00
2010-04-01 01:31:13 -07:00
2010-02-02 07:32:29 -08:00
2010-01-11 16:28:01 -08:00
2010-03-12 15:52:36 -08:00
2010-03-12 15:52:40 -08:00
2010-05-11 14:40:55 +02:00
2010-05-03 11:50:57 +02:00
2010-04-23 02:08:44 +02:00
2010-03-12 15:53:10 -08:00
2010-05-21 09:37:29 -07:00
2009-12-16 06:56:12 -08:00
2010-05-14 15:09:32 -04:00
2010-04-03 14:56:05 -07:00
2009-12-15 08:53:36 -08:00
2009-12-26 20:40:34 -08:00
2010-02-03 17:39:50 +11:00
2010-02-09 11:13:56 +01:00
2010-02-19 03:35:12 -05:00
2010-03-12 15:52:38 -08:00
2009-12-15 08:53:20 -08:00
2010-03-12 15:52:28 -08:00
2010-04-08 13:37:18 +02:00
2010-05-11 14:40:55 +02:00
2010-04-13 14:49:34 -07:00
2010-02-10 23:49:08 +09:00
2010-02-14 07:13:47 -07:00
2010-04-02 14:30:39 -07:00
2010-05-10 23:08:19 +02:00
2010-03-12 15:53:11 -08:00
2010-05-21 19:30:44 +02:00
2010-05-21 09:37:30 -07:00
2010-02-10 17:47:17 -08:00
2010-05-03 15:53:54 -07:00
2010-03-12 15:52:44 -08:00
2010-03-02 14:28:49 -05:00
2010-05-11 10:09:47 +02:00
2010-03-12 15:53:10 -08:00
2010-05-06 10:56:07 +10:00
2010-03-12 15:52:44 -08:00
2010-05-17 17:18:50 -07:00
2010-04-03 15:09:04 -07:00
2009-12-16 22:32:29 -05:00
2010-05-10 11:08:35 -07:00
2010-01-14 22:38:09 -05:00
2010-03-12 15:52:36 -08:00
2010-05-15 23:28:39 -07:00
2010-02-18 15:43:09 -08:00
2010-04-13 12:43:42 +02:00
2010-03-23 17:19:38 +01:00
2010-05-12 23:02:23 -07:00
2010-05-21 09:34:29 -07:00
2010-01-05 09:17:33 +09:00
2010-03-12 10:03:42 +01:00