linux-kernel - Re: [ANNOUNCE] 3.14.23-rt20

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.11.1411052357110.24960@nanos>
Date:	Thu, 6 Nov 2014 00:11:32 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Steven Rostedt <rostedt@...dmis.org>
cc:	Juerg Haefliger <juergh@...il.com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Carsten Emde <C.Emde@...dl.org>,
	John Kacur <jkacur@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Clark Williams <williams@...hat.com>
Subject: Re: [ANNOUNCE] 3.14.23-rt20

On Wed, 5 Nov 2014, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 23:29:32 +0100 (CET)
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > > > When we allow multiple readers, this will be allowed. But even in
> > > > mainline, if a writer were to come in and block between those two
> > > > down_read_trylocks(), the second trylock would fail.
> > > > 
> > > > PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> > > > be held by a single reader.
> > > 
> > > Errm. The reader holds the sem already. So that's a recursive read
> > > lock which should always succeed. And rt_read_trylock() has that
> > > implemented.
> > 
> > Bah. That's the rwlock path. Untested patch below should fix the issue.
> 
> This is basically a revert of my patch that removed rwsems as being
> recursive, because they are not recursive in mainline.

Well, they are. Just not in the presence of a writer.

Which is silly, but due to the fact that we do not track the readers
unavoidable. If the reader holds the sem already there is no real
reason why it should not succeed with the recursive lock.

If anything relies on that behaviour then we have a way bigger
problem at some other place.

> If you have the following:
> 
> 	down_read(&A);
> 
> 				down_write(&A);
> 
> 	down_read(&A);
> 
> in mainline, you will have a deadlock. With this change, it will not
> deadlock on -rt.

And that's fine on RT in the face of a single reader.

> This is probably why that cpu governor code uses down_read_trylock()
> otherwise, it would have suffered from possible deadlock scenarios.

Right.

> But, for a quick solution, just use this patch. I'll start working on
> the multi rwsem readers again, and then I'll have to revert this to do
> that. But when we have multi readers again, we wont need to have this
> hack.

And how exactly are multi reader rwsem solving that problem?

Not at all. You still need to track recursion of an already 'owning'
reader unless you want to add it twice on the 'owner' list.

Thanks,

	tglx






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