Re: locking/lockdep: Revert qrwlock recusive stuff

[Borislav Petkov]

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
> 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: ego@xxxxxxxxxxxxxxxxxx
> Cc: bp@xxxxxxxxx

Tested-by: Borislav Petkov <bp@xxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/