linux-kernel - Re: Q: schedule() and implied barriers on arm64

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:	Tue, 27 Oct 2015 16:19:48 +0000
From:	Will Deacon <will.deacon@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Ingo Molnar <mingo@...nel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Q: schedule() and implied barriers on arm64

On Mon, Oct 19, 2015 at 06:24:23PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 04:21:08PM +0100, Catalin Marinas wrote:
> > On Mon, Oct 19, 2015 at 09:06:05AM +0200, Ingo Molnar wrote:
> > > * Peter Zijlstra <peterz@...radead.org> wrote:
> > > 
> > > > In any case, its all moot now, since Paul no longer requires schedule() to imply 
> > > > a full barrier.
> > > >
> > > > [...]
> > > 
> > > Nevertheless from a least-surprise POV it might be worth guaranteeing it, because 
> > > I bet there's tons of code that assumes that schedule() is a heavy operation and 
> > > it's such an easy mistake to make. Since we are so close to having that guarantee, 
> > > we might as well codify it?
> > 
> > FWIW, the arm64 __switch_to() has a heavy barrier (DSB) but the reason
> > for this was to cope with potentially interrupted cache or TLB
> > maintenance (which require a DSB on the same CPU) and thread migration
> > to another CPU.
> 
> Right, but there's a path through schedule() that does not pass through
> __switch_to(); when we pick the current task as the most eligible task
> and next == prev.
> 
> In that case there really only is the wmb, a spin lock, an atomic op and
> a spin unlock (and a whole bunch of 'normal' code of course).

... and the 'normal' code will have a control hazard somewhere, followed
by the implicit ISB in exception return, so there's a barrier of sorts
there too.

The problem is that people say "full barrier" without defining what it
really means, and we end up going round the houses on things like
transitivity (which ctrl + isb doesn't always give you).

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