Messages in this thread | | | Subject | Re: [RT] bad BUG_ON in rtmutex.c | From | Steven Rostedt <> | Date | Tue, 18 Apr 2006 09:50:28 -0400 |
| |
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/
| |