linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	rt-users <linux-rt-users@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
Date: Fri, 09 Jul 2010 12:54:14 -0700	[thread overview]
Message-ID: <1278705254.2349.14.camel@localhost.localdomain> (raw)
In-Reply-To: <1278702134.5102.9.camel@localhost.localdomain>

On Fri, 2010-07-09 at 12:02 -0700, Fernando Lopez-Lezcano wrote:
> Ok, I got one! (had to go buy a null modem cable, I thought I had one
> but it has disappeared since the last time I did this :-)

Great! Sorry to make you go shopping! But this points out the problem
nicely.


> Find it below... it keeps spewing stuff every once in a while. Hopefully
> this will be enough. No response from the network or the keyboard or
> mouse at this point, reset is the only way out. 
> 
> I can retest if somebody comes up with a patch...
> Thanks.
> -- Fernando
> 
> localhost login: ------------[ cut here ]------------
> kernel BUG at kernel/rtmutex.c:808!

So that's a double lock deadlock.

> Call Trace:
>  [<facf45e6>] ? nfs_refresh_inode_locked+0x79c/0xa1e [nfs]
>  [<c0465523>] ? rt_spin_lock_fastlock.clone.1+0x26/0x5f
>  [<c07936b6>] ? rt_spin_unlock+0x8/0xa
>  [<c0465559>] ? rt_spin_lock_fastlock.clone.1+0x5c/0x5f
>  [<c07936a2>] ? rt_spin_lock+0x8/0xa
>  [<c04e08d3>] ? d_materialise_unique+0xa9/0x29e
>  [<facf55bc>] ? nfs_fhget+0x492/0x51d [nfs]
>  [<c07936b6>] ? rt_spin_unlock+0x8/0xa
>  [<facf15a0>] ? nfs_do_filldir+0x27b/0x3a9 [nfs]
>  [<c04dda9c>] ? filldir64+0x0/0xcb


Looking at d_materialise_unique, I see:

	/* Is this an anonymous mountpoint that we could splice
	 * into our tree? */
	if (IS_ROOT(alias)) {
		spin_lock(&alias->d_lock);
		__d_materialise_dentry(dentry, alias);
		__d_drop(alias);
		goto found;
	}

The problem being that __d_materialise_dentry then tries to lock
alias->d_lock and we hang.

Not sure if the following is the right fix but it should avoid the
deadlock. Mind testing it to verify things work ok?

Nick: Any race possibility if something catches us between
__d_materialise_dentry and d_drop? Or should this be ok?


Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff --git a/fs/dcache.c b/fs/dcache.c
index c9d21ae..d37f6f4 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2159,8 +2159,8 @@ struct dentry *d_materialise_unique(struct dentry *dentry, struct inode *inode)
 			/* Is this an anonymous mountpoint that we could splice
 			 * into our tree? */
 			if (IS_ROOT(alias)) {
-				spin_lock(&alias->d_lock);
 				__d_materialise_dentry(dentry, alias);
+				spin_lock(&alias->d_lock);
 				__d_drop(alias);
 				goto found;
 			}



  parent reply	other threads:[~2010-07-09 19:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-08 17:19 2.6.33.5 rt23: machine lockup (nfs/autofs related?) Fernando Lopez-Lezcano
2010-07-08 22:33 ` john stultz
2010-07-08 22:44   ` Fernando Lopez-Lezcano
2010-07-08 23:00     ` john stultz
2010-07-09 19:02       ` Fernando Lopez-Lezcano
2010-07-09 19:13         ` Fernando Lopez-Lezcano
2010-07-09 19:54         ` john stultz [this message]
2010-07-09 22:13           ` Fernando Lopez-Lezcano
2010-07-09 22:31             ` john stultz
2010-07-09 23:07               ` Fernando Lopez-Lezcano
2010-07-09 23:24                 ` Fernando Lopez-Lezcano
2010-07-09 22:57             ` john stultz
2010-07-09 23:13               ` Fernando Lopez-Lezcano
2010-07-12 23:37               ` Fernando Lopez-Lezcano
2010-07-12 23:53                 ` john stultz
2010-07-13  1:10                   ` Fernando Lopez-Lezcano
2010-07-13  1:40                     ` john stultz
2010-07-13  3:06                       ` Fernando Lopez-Lezcano
2010-07-14 21:32                         ` Fernando Lopez-Lezcano
2010-07-14 21:36                           ` john stultz
2010-07-14 22:02                             ` Fernando Lopez-Lezcano

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=1278705254.2349.14.camel@localhost.localdomain \
    --to=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=nando@ccrma.Stanford.EDU \
    --cc=npiggin@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).