On Tue, Sep 30, 2014 at 03:26:00PM +0200, Peter Zijlstra wrote:
>
> Now with locking self test reverted too and extra changelog.
>
>
> ---
> Subject: locking/lockdep: Revert qrwlock recusive stuff
> From: Peter Zijlstra <pet...@infradead.org>
> Date: Tue, 30 Sep 2014 14:48:07 +0200
>
> Commit f0bab73cb539 ("locking/lockdep: Restrict the use of recursive
> read_lock() with qrwlock") changed lockdep to try and conform to the
> qrwlock semantics which differ from the traditional rwlock semantics.
>
> In particular qrwlock is fair outside of interrupt context, but in
> interrupt context readers will ignore all fairness.
>
> The problem modeling this is that read and write side have different
> lock state (interrupts) semantics but we only have a single
> representation of these. Therefore lockdep will get confused, thinking
> the lock can cause interrupt lock inversions.
>
> So revert for now; the old rwlock semantics were already imperfectly
> modeled and the qrwlock extra won't fit either.
>
> If we want to properly fix this, I think we need to resurrect the work
> by Gautham did a few years ago that split the read and write state of
> locks:
>
> http://lwn.net/Articles/332801/
>
> FWIW the locking selftest that would've failed (and was reported by
> Borislav earlier) is something like:
>
> RL(X1); /* IRQ-ON */
> LOCK(A);
> UNLOCK(A);
> RU(X1);
>
> IRQ_ENTER();
> RL(X1); /* IN-IRQ */
> RU(X1);
> IRQ_EXIT();
>
> At which point it would report that because A is an IRQ-unsafe lock we
> can suffer the following inversion:
>
> CPU0 CPU1
>
> lock(A)
> lock(X1)
> lock(A)
> <IRQ>
> lock(X1)
>
> And this is 'wrong' because X1 can recurse (assuming the above lock are
> in fact read-lock) but lockdep doesn't know about this.
>
> Cc: e...@linux.vnet.ibm.com
> Cc: b...@alien8.de
Tested-by: Borislav Petkov <b...@suse.de>
Thanks!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
