All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@mvista.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RT] bad BUG_ON in rtmutex.c
Date: Tue, 18 Apr 2006 06:11:25 -0700	[thread overview]
Message-ID: <1145365886.5447.28.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0604180831390.9005@gandalf.stny.rr.com>

On Tue, 2006-04-18 at 08:34 -0400, Steven Rostedt wrote:
> On Tue, 18 Apr 2006, Daniel Walker wrote:
> 
> > On Mon, 2006-04-17 at 21:48 -0400, Steven Rostedt wrote:
> > ...
> > >
> > > So the question now is: is this a real bug?
> >
> > It seems like a possible scenario . So if the false BUG_ON() needlessly
> > kills a perfectly running system, then it must be a bug. It's the case
> > of the buggy BUG_ON ;) !
> >
> 
> It was late when I was writing that.  I reread my email today, and realize
> that there's a few confusing statements there.  That last one being one :)

Yeah , it was a bit confusing .

> I meant to say:
> 
>   So the question is now: Is that case in BUG_ON a real bug?
> 
> The BUG_ON bugging a normal system _is_ a bug.

Something in the code bothered me right around the block you
referenced. 

Specifically when it drops the pi_lock , then takes it again, then does
plist_add to the pi_waiters ( during the "Boost the owner" section in
rt_mutex_adjust_prio_chain() ). Since the pi_lock was dropped you could
get an priority change which would lead to a bogus value in
waiter->pi_list_entry.prio .

I was looking over the code, and it seems like once all the chain
adjusting bottoms out you would end up with the correct priorities in
the waiter structures .. Cause whatever task made the priority
adjustment would just end up resetting the pi_waiters during it's
adjustment process. (Seems like there's room for optimization
though ..) 

Daniel


  reply	other threads:[~2006-04-18 13:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-18  1:48 [RT] bad BUG_ON in rtmutex.c Steven Rostedt
2006-04-18 12:20 ` Daniel Walker
2006-04-18 12:34   ` Steven Rostedt
2006-04-18 13:11     ` Daniel Walker [this message]
2006-04-18 13:50       ` Steven Rostedt
2006-04-18 13:55         ` Steven Rostedt
2006-04-18 14:09         ` Daniel Walker
2006-04-18 14:32           ` Steven Rostedt
2006-04-18 14:51             ` Daniel Walker
2006-04-18 13:52               ` Ingo Molnar
2006-04-18 15:06               ` Steven Rostedt
2006-04-18 16:14                 ` Daniel Walker
2006-04-18 16:24                   ` Steven Rostedt
2006-04-18 14:13 ` [PATCH -rt] Remove false BUG_ON from rtmutex.c Steven Rostedt
2006-04-18 13:12   ` Ingo Molnar

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=1145365886.5447.28.camel@localhost.localdomain \
    --to=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.