[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305907896.1465.27.camel@gandalf.stny.rr.com>
Date: Fri, 20 May 2011 12:11:36 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Darren Hart <dvhart@...ux.intel.com>
Cc: richard -rw- weinberger <richard.weinberger@...il.com>,
Toralf Förster <toralf.foerster@....de>,
LKML <linux-kernel@...r.kernel.org>,
user-mode-linux-devel@...ts.sourceforge.net
Subject: Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
On Fri, 2011-05-20 at 12:04 -0400, Steven Rostedt wrote:
> On Fri, 2011-05-20 at 08:55 -0700, Darren Hart wrote:
>
> > I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
> >
> > if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> > || plist_node_empty(&q->list)))
> >
> > Toralf, can you instrument that let us know which of conditions is
> > triggering the WARN_ON? Something like the following should be adequate
> > to get you the line number. I suspect it is plist_node_empty give the
> > git bisect results you reported.
> >
> >
> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index abd5324..7f31bca 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
> > {
> > struct futex_hash_bucket *hb;
> >
> > - if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> > - || plist_node_empty(&q->list)))
> > + if (WARN_ON(!q->lock_ptr))
> > + return;
> > + if (!spin_is_locked(q->lock_ptr))
> > + return;
> > + if (plist_node_empty(&q->list))
> > return;
> >
>
> Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
>
> I think UML is UP, and that spin_is_locked() will always return false.
>
Could you apply these patches:
2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
29096202 futex: Fix WARN_ON() test for UP
On top of this commit, and see if the problem goes away. What could have
happened, is that you have two bugs, with one of them fixed. If the git
bisect stumbled on this bug, it will show this one, even though later
on, this code was fixed. If you apply the above two patches and it works
again, then this isn't the bug you are looking for.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists