Messages in this thread | | | Date | Tue, 24 Oct 2006 14:19:02 +0200 (CEST) | From | Esben Nielsen <> | Subject | Re: rtmutex's wait_lock in 2.6.18-rt7 |
| |
On Tue, 24 Oct 2006, Thomas Gleixner wrote:
> On Mon, 2006-10-23 at 11:55 +0200, Esben Nielsen wrote: >> Hi, >> I see that in 2.6.18-rt7 the rtmutex's wait_lock is sudden interrupt >> disabling. I don't see the need as no (hard) interrupt-handlers should be >> touching any mutex. > > It does not touch mutexes, but the dynamic priority adjustment of the > hrtimer softirq needs it. > > The correct solution will be moving the timer callback into the process > context, as it will be woken up anyway, but that's more complex to do > than it looks in the first place. >
I have send out patches doing the correct priority adjustment without touching the wait_lock. Why not use that?
I found it in the archives: http://www.uwsg.iu.edu/hypermail/linux/kernel/0610.0/0049.html (or more specific in http://www.uwsg.iu.edu/hypermail/linux/kernel/0610.0/0051.html, look for changes to sched.c)
It is very bad to do PI traversal in interrupt context. In the general case, where there are user-space locks, that operation unbounded. I know that in your case you can only traverse kernel locks, but I think it is bad to open for such posibilities if it can be avoided.
Esben
> tglx > > - 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/
| |