Messages in this thread | | | Date | Tue, 12 Apr 2005 22:35:35 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [PATCH] Priority Lists for the RT mutex |
| |
I looked at the PI-code to see what priority the task (old_owner below) would end up with when it released a lock. From rt.c:
prio = mutex_getprio(old_owner); if (new_owner && !plist_empty(&new_owner->pi_waiters)) { w = plist_entry(&new_owner->pi_waiters, struct rt_mutex_waiter, pi_list); prio = w->task->prio; } if (prio != old_owner->prio) pi_setprio(lock, old_owner, prio);
What has new_owner to do with it? Shouldn't it be old_owner in these lines? I.e. the prio we want to set old_owner to should be the prio of the head of the old_owner->pi_waiters, not the new_owner!
Esben
On Mon, 11 Apr 2005, Ingo Molnar wrote:
> > * Perez-Gonzalez, Inaky <inaky.perez-gonzalez@intel.com> wrote: > > > Let me re-phrase then: it is a must have only on PI, to make sure you > > don't have a loop when doing it. Maybe is a consequence of the > > algorithm I chose. -However- it should be possible to disable it in > > cases where you are reasonably sure it won't happen (such as kernel > > code). In any case, AFAIR, I still did not implement it. > > are there cases where userspace wants to disable deadlock-detection for > its own locks? > > the deadlock detector in PREEMPT_RT is pretty much specialized for > debugging (it does all sorts of weird locking tricks to get the first > deadlock out, and to really report it on the console), but it ought to > be possible to make it usable for userspace-controlled locks as well. > > Ingo >
- 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/
| |