Re: [PATCH] sched/core: avoid spurious spinlock recursion splats

2018-02-06 Thread Mark Rutland
On Tue, Feb 06, 2018 at 11:03:07AM +0100, Peter Zijlstra wrote: > On Mon, Feb 05, 2018 at 03:51:18PM +, Mark Rutland wrote: > > However, this happens *after* prev->on_cpu is cleared, which allows prev > > to be scheduled on another CPU. If prev then attempts to acquire the > > same rq lock, bef

Re: [PATCH] sched/core: avoid spurious spinlock recursion splats

2018-02-06 Thread Peter Zijlstra
On Mon, Feb 05, 2018 at 03:51:18PM +, Mark Rutland wrote: > However, this happens *after* prev->on_cpu is cleared, which allows prev > to be scheduled on another CPU. If prev then attempts to acquire the > same rq lock, before the updated rq->lock.owner is made visible, it will > see itself as

[PATCH] sched/core: avoid spurious spinlock recursion splats

2018-02-05 Thread Mark Rutland
The runqueue locks are special in that the owner changes over a context switch. To ensure that this is accounted for in CONFIG_DEBUG_SPINLOCK builds, finish_lock_switch updates rq->lock.owner while the lock is held. However, this happens *after* prev->on_cpu is cleared, which allows prev to be sch