sched: fix possible recursive rq->lock
authorPeter Zijlstra <a.p.zijlstra@chello.nl>
Wed, 7 Jan 2009 14:28:57 +0000 (15:28 +0100)
committerIngo Molnar <mingo@elte.hu>
Wed, 7 Jan 2009 15:10:54 +0000 (16:10 +0100)
commitda8d5089da6dfd54e5fd05d0c291a63c2bcf6885
treead9f7deceed846e56e0185976af5c620722ff9ba
parentede6f5aea054d3fb67c78857f7abdee602302043
sched: fix possible recursive rq->lock

Vaidyanathan Srinivasan reported:

 > =============================================
 > [ INFO: possible recursive locking detected ]
 > 2.6.28-autotest-tip-sv #1
 > ---------------------------------------------
 > klogd/5062 is trying to acquire lock:
 >  (&rq->lock){++..}, at: [<ffffffff8022aca2>] task_rq_lock+0x45/0x7e
 >
 > but task is already holding lock:
 >  (&rq->lock){++..}, at: [<ffffffff805f7354>] schedule+0x158/0xa31

With sched_mc at 2. (it is default-off)

Strictly speaking we'll not deadlock, because ttwu will not be able to
place the migration task on our rq, but since the code can deal with
both rqs getting unlocked, this seems the easiest way out.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched.c