On Thu, Jul 24, 2014 at 02:25:13PM +0200, Borislav Petkov wrote:
> On Thu, Jul 24, 2014 at 10:41:27AM +0200, Borislav Petkov wrote:
> > you can easily reproduce by booting a kvm guest with rc6 + tip/master.
>
> Right, so reverting
>
> 586fefe5bbdc ("locking/selftest: Support queued rwlock")
> e0645a111cb4 ("locking/lockdep: Restrict the use of recursive read_lock() with qrwlock")
>
> from the top of tip/locking/core seems to fix the issue, with the kvm
> guests at least.
Well, it makes the report go away.. I'm currently leaning towards that
the report is valid. We did after all change rwlock semantics, and that
lockdep patch is making lockdep match those new semantics.
Of course, its also possible the lockdep patch is wrong. But I'm leaning
towards that the report is valid.
So going by the nifty picture rostedt made:
[ 61.454336] CPU0 CPU1
[ 61.454336] ---- ----
[ 61.454336] lock(&(&p->alloc_lock)->rlock);
[ 61.454336] local_irq_disable();
[ 61.454336] lock(tasklist_lock);
[ 61.454336] lock(&(&p->alloc_lock)->rlock);
[ 61.454336] <Interrupt>
[ 61.454336] lock(tasklist_lock);
the fact that CPU1 holds tasklist_lock for reading, does not
automagically allow CPU0 to acquire tasklist_lock for reading too, for
example if CPU2 (not in the picture) is waiting to acquire tasklist_lock
for writing, CPU0's read acquire is made to wait.
The only kind of recursion that's safe is same CPU interrupt.
Of course we should have made the lockdep change before merging qrwlock,
and that's entirely my fail, but with qrwlock in these new semantics are
already a reality.
We could of course disable qrwlock until all such issues are cleared up
(its the safe option)...
Attachment:
pgpq6nB7EHAOK.pgp
Description: PGP signature
