Messages in this thread |  | | Date | Wed, 5 Nov 2008 14:09:36 +0100 | From | "Zdenek Kabelac" <> | Subject | Re: sys_sched_yield keeps locked irq before call of schedule() |
| |
2008/11/5 Ingo Molnar <mingo@elte.hu>: > > * Zdenek Kabelac <zdenek.kabelac@gmail.com> wrote: > >> Hi >> >> With recent 2.6.28-rc3 kernel I've noticed that schedule() is >> sometime being called with locked IRQ >> >> Call Trace: >> [<ffffffff81334592>] _spin_lock_irq+0x92/0xa0 >> [<ffffffff8133126b>] schedule+0x13b/0x4cb >> [<ffffffff81013c10>] ? native_sched_clock+0x70/0xa0 >> [<ffffffff81040930>] ? sys_sched_yield+0x0/0x80 >> [<ffffffff810409a5>] sys_sched_yield+0x75/0x80 >> [<ffffffff8100c6bb>] system_call_fastpath+0x16/0x1b > > is this some special warning you added? The stock kernel certainly > does not emit this warning.
Yes - it's my personal debug checker that tries to watch wether irq & irqsafe are running in pair. So it shows a warning if there is a call of spin_lock_irq and irq is already dissabled.
> >> Which is a result of the function sys_sched_yield() that calls >> schedule() while it keeps irq. >> >> Is it correct to call the function schedule() which 'usually' >> expects irq being unlocked and do some 'lenghty' operations (i.e. >> debug statistics) which do not need to keep irq locked for such a >> long time? > > the debug statistics are all fast and we disable interrupts straight > away when entering the schedule().
IRQ is disabled with spin_lock_irc() inside schedule() and it looks like there is quite a few lines above which receive 'extra' bonus with being run without enabled irq, but as I said - I'm just checking whether this is intentional or not.
Zdenek
|  |