On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> 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);
So this *should* be fine. It always has been in the past, and it was
certainly the *intention* that it should continue to work with
qrwlock, even in the presense of pending writers on other cpu's.
The qrwlock rules are that a read-lock in an interrupt is still going
to be unfair and succeed if there are other readers.
> 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.
No.
That is true for qrwlock in general. But *not* in interrupt context.
In interrupt context, it's unfair. At least that was the _intent_ of
the code, maybe that got screwed up some way.
> The only kind of recursion that's safe is same CPU interrupt.
Any read-lock from an irq should still be unfair, no "same CPU" rules.
See queue_read_lock_slowpath(), where it will just wait for any actual
write lockers (not *waiting* writers) to go away. So by definition, of
somebody else (not just the current CPU) holds the lock for reading,
taking it for reading is safe on all cpu's in irq context, because we
obviously won't be waiting for any actual write lock holders.
So it sounds to me like the new lockdep rules in tip/master are too
strict and are throwing a false positive.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
