diff options
author | Peter Zijlstra <a.p.zijlstra@chello.nl> | 2008-08-11 09:30:22 +0200 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2008-08-11 09:30:22 +0200 |
commit | 1b12bbc747560ea68bcc132c3d05699e52271da0 (patch) | |
tree | 0e0fe5b7fe07d411251eebdd053e9e7793820248 /virt | |
parent | 64aa348edc617dea17bbd01ddee4e47886d5ec8c (diff) | |
download | kernel_samsung_smdk4412-1b12bbc747560ea68bcc132c3d05699e52271da0.zip kernel_samsung_smdk4412-1b12bbc747560ea68bcc132c3d05699e52271da0.tar.gz kernel_samsung_smdk4412-1b12bbc747560ea68bcc132c3d05699e52271da0.tar.bz2 |
lockdep: re-annotate scheduler runqueues
Instead of using a per-rq lock class, use the regular nesting operations.
However, take extra care with double_lock_balance() as it can release the
already held rq->lock (and therefore change its nesting class).
So what can happen is:
spin_lock(rq->lock); // this rq subclass 0
double_lock_balance(rq, other_rq);
// release rq
// acquire other_rq->lock subclass 0
// acquire rq->lock subclass 1
spin_unlock(other_rq->lock);
leaving you with rq->lock in subclass 1
So a subsequent double_lock_balance() call can try to nest a subclass 1
lock while already holding a subclass 1 lock.
Fix this by introducing double_unlock_balance() which releases the other
rq's lock, but also re-sets the subclass for this rq's lock to 0.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions