Re: [RT] bad BUG_ON in rtmutex.c

[Daniel Walker <dwalker@mvista.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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/