Lockdep splat in autofs with 2.6.39-rc2

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

=============================================
[ INFO: possible recursive locking detected ]
2.6.39-rc2 #177
---------------------------------------------
automount/23324 is trying to acquire lock:

   (&(&dentry->d_lock)->rlock/1){+.+...}, at: [<ffffffffa034ea28>]

autofs4_expire_indirect+0x307/0x484 [autofs4]

but task is already holding lock:

   (&(&dentry->d_lock)->rlock/1){+.+...}, at: [<ffffffffa034ea28>]

autofs4_expire_indirect+0x307/0x484 [autofs4]

other info that might help us debug this:
2 locks held by automount/23324:

   #0:  (&(&sbi->lookup_lock)->rlock){+.+...}, at: [<ffffffffa034e9aa>]
autofs4_expire_indirect+0x289/0x484 [autofs4] #1: 
(&(&dentry->d_lock)->rlock/1){+.+...}, at: [<ffffffffa034ea28>]
autofs4_expire_indirect+0x307/0x484 [autofs4]

  stack backtrace:
  Pid: 23324, comm: automount Not tainted 2.6.39-rc2 #177
  Call Trace:
   [<ffffffff81061dc7>] __lock_acquire+0xc83/0xcfa
   [<ffffffff8105f200>] ? static_obj+0x3d/0x4d
   [<ffffffff81062073>] ? lock_release_non_nested+0x1c8/0x227
   [<ffffffffa034ea28>] ? autofs4_expire_indirect+0x307/0x484 [autofs4]
   [<ffffffffa034ea28>] ? autofs4_expire_indirect+0x307/0x484 [autofs4]
   [<ffffffff81061e95>] lock_acquire+0x57/0x6d
   [<ffffffffa034ea28>] ? autofs4_expire_indirect+0x307/0x484 [autofs4]
   [<ffffffff8131f4e3>] _raw_spin_lock_nested+0x39/0x48
   [<ffffffffa034ea28>] ? autofs4_expire_indirect+0x307/0x484 [autofs4]
   [<ffffffff8131fb10>] ? _raw_spin_unlock+0x3e/0x4b
   [<ffffffffa034ea28>] autofs4_expire_indirect+0x307/0x484 [autofs4]
   [<ffffffffa034f184>] ? autofs_dev_ioctl_askumount+0x2d/0x2d [autofs4]
   [<ffffffffa034edbd>] autofs4_do_expire_multi+0x30/0xe9 [autofs4]
   [<ffffffffa034f184>] ? autofs_dev_ioctl_askumount+0x2d/0x2d [autofs4]
   [<ffffffffa034f184>] ? autofs_dev_ioctl_askumount+0x2d/0x2d [autofs4]
   [<ffffffffa034f19e>] autofs_dev_ioctl_expire+0x1a/0x1c [autofs4]
   [<ffffffffa034f738>] _autofs_dev_ioctl+0x2a3/0x348 [autofs4]
   [<ffffffffa034f7eb>] autofs_dev_ioctl+0xe/0x12 [autofs4]
   [<ffffffff810c750d>] do_vfs_ioctl+0x45f/0x4ae
   [<ffffffff810bab4e>] ? rcu_read_unlock+0x21/0x23
   [<ffffffff810c759e>] sys_ioctl+0x42/0x65
   [<ffffffff8132463b>] system_call_fastpath+0x16/0x1b

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=33242 for your bug report, please add your address to the CC list in there, thanks!

Quoted 3 lines · Maciej Rutecki

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=33242 for your bug report, please add your address to the CC list in there, thanks!

Unfortunately, that site does not appear to let me add this email to the CC list:

Kernel Bug Tracker was unable to make any match at all for one or more of the names and/or email addresses you entered on the previous page. Please go back and try other names or email addresses.

CC [email protected] did not match anything

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Quoted 4 lines · Nick Bowler

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Could you try this patch. I know it may be hard to reproduce, but the issue is that we are recursing down the locks in a tree/list and we changed a lock from being nested to being a parent. This patch tells lockdep about what we did.

Quoted 6 lines · Steven Rostedt

Quoted 4 lines · Nick Bowler

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Quoted 4 lines

Could you try this patch. I know it may be hard to reproduce, but the issue is that we are recursing down the locks in a tree/list and we changed a lock from being nested to being a parent. This patch tells lockdep about what we did.

OK, I've built 2.6.39-rc5 with this patch applied. However, it took ~5 days before I saw any splat with -rc4, thus it's unlikely that I'll be able to say for sure that it works.

Quoted 12 lines · Nick Bowler

Quoted 10 lines · Steven Rostedt

Quoted 4 lines · Nick Bowler

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Could you try this patch. I know it may be hard to reproduce, but the issue is that we are recursing down the locks in a tree/list and we changed a lock from being nested to being a parent. This patch tells lockdep about what we did.

Quoted 3 lines

OK, I've built 2.6.39-rc5 with this patch applied. However, it took ~5 days before I saw any splat with -rc4, thus it's unlikely that I'll be able to say for sure that it works.

FWIW, haven't had any problems with this kernel (+ patch) during the last two weeks.

I'm going to wrap this up and send it out as a proper patch. Can I add your "Reported-by" and "Tested-by" tags?

Quoted 5 lines · Nick Bowler

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Could you try this patch. I know it may be hard to reproduce, but the issue is that we are recursing down the locks in a tree/list and we changed a lock from being nested to being a parent. This patch tells lockdep about what we did.

Signed-off-by Steven Rostedt <[email protected]>

fs/autofs4/expire.c +2 -0

index 450f529..1feb68e 100644
@@ -124,6 +124,7 @@ start:
 	/* Negative dentry - try next */
 	if (!simple_positive(q)) {
 		spin_unlock(&p->d_lock);
+		lock_set_subclass(&q->d_lock.dep_map, 0, _RET_IP_);
 		p = q;
 		goto again;
 	}

@@ -186,6 +187,7 @@ again:
 	/* Negative dentry - try next */
 	if (!simple_positive(ret)) {
 		spin_unlock(&p->d_lock);
+		lock_set_subclass(&ret->d_lock.dep_map, 0, _RET_IP_);
 		p = ret;
 		goto again;
 	}

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Quoted 12 lines · Steven Rostedt

Quoted 5 lines · Nick Bowler

Just saw this on 2.6.39-rc2 after half a day or so of uptime. I've never seen it before today so it may be a regression from 2.6.38. Nothing seems have failed as a result. Please let me know if you need any more info.

Could you try this patch. I know it may be hard to reproduce, but the issue is that we are recursing down the locks in a tree/list and we changed a lock from being nested to being a parent. This patch tells lockdep about what we did.

Quoted 1 line

Signed-off-by Steven Rostedt <[email protected]>

Hi Steven,

It appears this is not included in current mainline yet so I'm guessing it is still a problem.

Is this the correct way to handle the problem?

Do you want me to forward the patch to Al Viro for inclusion in his tree and subsequent inclusion in mainline or would you like to do that?