Messages in this thread Patch in this message |  | | Date | Wed, 5 Nov 2008 13:57:27 +0100 | From | "Zdenek Kabelac" <> | Subject | sys_sched_yield keeps locked irq before call of schedule() |
| |
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
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?
I've no idea whether this bug or feature and for now I'm using this simple patch to fix this issue.
diff --git a/kernel/sched.c b/kernel/sched.c index e8819bc..80eb633 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -5546,6 +5546,7 @@ asmlinkage long sys_sched_yield(void) spin_release(&rq->lock.dep_map, 1, _THIS_IP_); _raw_spin_unlock(&rq->lock); preempt_enable_no_resched(); + local_irq_enable();
schedule();
Zdenek
|  |