Re: locking/lockdep: Revert qrwlock recusive stuff
From: Borislav Petkov
Date: Tue Sep 30 2014 - 12:17:31 EST
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 <peterz@xxxxxxxxxxxxx>
> 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
> FWIW the locking selftest that would've failed (and was reported by
> Borislav earlier) is something like:
> RL(X1); /* IRQ-ON */
> RL(X1); /* IN-IRQ */
> At which point it would report that because A is an IRQ-unsafe lock we
> can suffer the following inversion:
> CPU0 CPU1
> 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: ego@xxxxxxxxxxxxxxxxxx
> Cc: bp@xxxxxxxxx
Tested-by: Borislav Petkov <bp@xxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/