linux-kernel - Re: [PATCH] ib-release-locks-in-the-proper-order

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]

Date:	Mon, 21 Sep 2009 17:17:47 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	John Kacur <jkacur@...hat.com>
Cc:	mingo@...e.hu, Roland Dreier <rolandd@...co.com>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>, tglx@...utronix.de,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ib-release-locks-in-the-proper-order

On Mon, 2009-09-21 at 21:35 +0200, John Kacur wrote:
> Please consider the following patch - originally from Steven Rostedt. 
> It solves a problem for rt which is very sensitive to the lock ordering. 
> It should have a no impact on non-rt.
> 
> The patch applies to current tip/master - but it is fine with me if it 
> would be more appropriate for one of the infiniband people to take it.
> 
> Thanks
> 
> >From e533f2b9ee9b0bd95aaa4c3369e79b350c9895d3 Mon Sep 17 00:00:00 2001
> From: Steven Rostedt <srostedt@...hat.com>
> Date: Mon, 21 Sep 2009 21:23:46 +0200
> Subject: [PATCH] ib: release locks in the proper order
> 
> RT is very sensitive to the order locks are taken and released
> wrt read write locks. We must do
> 
>   lock(a);
>   lock(b);
>   lock(c);
> 
>   [...]
> 
>   unlock(c);
>   unlock(b);
>   unlock(a);
> 
> otherwise bad things can happen.
> 
> Signed-off-by: Ken Cox <jkc@...hat.com>
> Signed-off-by: Clark Williams <williams@...hat.com>
> Signed-off-by: John Kacur <jkacur@...hat.com>

The -rt patch doesn't use the multi rwlock code anymore (the reason for
the first patch), and the last revision of that code was able to handle
that too.

Linus totally ripped into this idea. A lock must be able to handle any
order of unlocking. There should be no technical reason a lock must be
unlocked in reverse order they were locked.

What exactly is sensitive about this?

-- Steve


--
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/