linux-kernel - Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS

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:	Thu, 16 Apr 2015 20:15:35 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>, Mel Gorman <mel@....ul.ie>,
	Rik van Riel <riel@...hat.com>,
	Jason Low <jason.low2@...com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mel Gorman <mgorman@...e.de>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	hideaki.kimura@...com, Aswin Chandramouleeswaran <aswin@...com>,
	Scott J Norton <scott.norton@...com>
Subject: Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the
 scheduler

On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
> > ACCESS_ONCE() is not a compiler barrier
> 
> It's not a general compiler barrier (and I didn't claim so) but it is 
> still a compiler barrier: it's documented as a weak, variable specific 
> barrier in Documentation/memor-barriers.txt:

Ok, fair enough. I just don't generally think of them as 'barriers'.

> > The 'read' side uses ACCESS_ONCE() for two purposes:
> >  - to load the value once, we don't want the seq number to change under
> >    us for obvious reasons
> >  - to avoid load tearing and observe weird seq numbers
> > 
> > The update side uses ACCESS_ONCE() to avoid write tearing, and 
> > strictly speaking it should also worry about read-tearing since its 
> > not hard serialized, although its very unlikely to actually have 
> > concurrency (IIRC).

> This is what I meant by that there's no harm from this race.

Ok, but I would still like to preserve the READ one on the usage site
and the WRITE one on the update side, if only as documentation that
there's something 'special' happening.

And while the effects here might end up being statistical noise, I have
conceptual problems with re-reading seq counts, that's not proper.

And its not like they really cost anything.
--
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/