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>
This commit is contained in:
Peter Zijlstra 2009-01-07 15:28:57 +01:00 committed by Ingo Molnar
parent ede6f5aea0
commit da8d5089da
1 changed files with 5 additions and 0 deletions

View File

@ -3728,8 +3728,13 @@ redo:
}
double_unlock_balance(this_rq, busiest);
/*
* Should not call ttwu while holding a rq->lock
*/
spin_unlock(&this_rq->lock);
if (active_balance)
wake_up_process(busiest->migration_thread);
spin_lock(&this_rq->lock);
} else
sd->nr_balance_failed = 0;