[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subjectsys_sched_yield keeps locked irq before call of schedule()

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_);
+ local_irq_enable();



 \ /
  Last update: 2008-11-05 13:59    [W:1.013 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site