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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
