Re: [RT] bad BUG_ON in rtmutex.c

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2006-04-18 at 06:11 -0700, Daniel Walker wrote:

> 
> 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 .

It's not really bogus. It just wont match the task->prio.  The
waiter->pi_list_entry.prio is set to waiter->list_entry.prio and that's
what you really need to match.  But you are right that the prio could
have changed.  But whoever changed the prio should also be updating the
chain, so whoever finishes, should have the chain setup properly.

> 
> 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 ..) 

I guess I just reiterated above what you are saying here.  Not sure if
this can be optimized.  You're talking about optimizing a case that
would seldom happen, but in doing so you stand a great chance of slowing
down the normal case.

To keep latencies down, we are letting the PI chain walk be preempted,
by releasing locks.  It's understood that the chain can then change
while walking (big debate about this between Ingo, tglx and Esben).  But
at the end, we decided on it being better to have latencies down, and
just make adjustments when they arise.  This also keeps the latencies
bounded, since the old way was harder to know the worst case (PI chain
creep).

BUT!  I need to take another good look at the code, and maybe my
previous example of the failed BUG_ON is really a clue that there exists
a deeper bug.  If the processes D and E from my last example were of
different priorities, but still higher than A, could the end result be
setting A to the lower of the two?  This would be a bug, because then A
would not inherit the correct priority!

-- Steve


-
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/