sys_sched_yield keeps locked irq before call of schedule()

["Zdenek Kabelac" <zdenek.kabelac@gmail.com>]

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