linux-kernel - Re: locking/lockdep: Revert qrwlock recusive stuff

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140930161723.GA4473@pd.tnic>
Date:	Tue, 30 Sep 2014 18:17:23 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	mingo@...nel.org, linux-kernel@...r.kernel.org,
	ego@...ux.vnet.ibm.com, Waiman.Long@...com
Subject: Re: locking/lockdep: Revert qrwlock recusive stuff

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@...radead.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: ego@...ux.vnet.ibm.com
> Cc: bp@...en8.de

Tested-by: Borislav Petkov <bp@...e.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/