Messages in this thread | | | Date | Mon, 13 Nov 2006 11:39:27 +0100 (CET) | From | Esben Nielsen <> | Subject | Re: [patch 1/5] Fix timeout bug in rtmutex in 2.6.18-rt |
| |
On Fri, 10 Nov 2006, Ingo Molnar wrote:
> > on SMP i had to remove this assert: > > Index: linux/kernel/rtmutex.c > =================================================================== > --- linux.orig/kernel/rtmutex.c > +++ linux/kernel/rtmutex.c > @@ -823,7 +823,7 @@ rt_spin_lock_slowunlock(struct rt_mutex > } > wakeup_next_waiter(lock, 1); > spin_unlock_irqrestore(&lock->wait_lock, flags); > - BUG_ON(current->boosting_prio != MAX_PRIO); > +// BUG_ON(current->boosting_prio != MAX_PRIO); > /* Undo pi boosting.when necessary */ > rt_mutex_adjust_prio(current); > } > > because it triggered almost immediately after bootup. >
Hmm, boosting_prio should be MAX_PRIO at that point. boosting_prio should only be different from MAX_PRIO while a task is trying to lock a mutex - i.e. while it is in a *_slowlock() function.
On which kernel have you applied the patch?
I am looking at 2.6.18-rt6 and trying to see if there is a race conditions. I can't see it that easily (or I would probably have seen it already :-). task->boosting_prio is not set when task->pi_lock is not taken. And then it is only set to something else than MAX_PRIO if task->pi_blocked_on is set.
> Ingo >
Esben - 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/
| |