linux-kernel - Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86)

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: <20150317233629.GA8578@thin>
Date:	Tue, 17 Mar 2015 16:36:30 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Nicholas Miell <nmiell@...cast.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Alan Cox <gnomes@...rguk.ukuu.org.uk>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Howells <dhowells@...hat.com>
Subject: Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory
 barrier (x86)

On Tue, Mar 17, 2015 at 07:01:23PM +0000, Mathieu Desnoyers wrote:
> ----- Original Message -----
> > On Tue, Mar 17, 2015 at 10:57:50AM -0700, josh@...htriplett.org wrote:
> > > On Tue, Mar 17, 2015 at 06:30:35PM +0100, Peter Zijlstra wrote:
> > > > On Tue, Mar 17, 2015 at 01:22:02PM -0400, Mathieu Desnoyers wrote:
> > > > > Here is an implementation of a new system call, sys_membarrier(), which
> > > > > executes a memory barrier on either all running threads of the current
> > > > > process (MEMBARRIER_PRIVATE) issues a memory barrier on all threads
> > > > > running on the system (~MEMBARRIER_PRIVATE). Both are currently
> > > > > implemented by calling synchronize_sched().
> > > > 
> > > > Then why bother with the flag?
> > > 
> > > Semantically, MEMBARRIER_PRIVATE is allowed to avoid issuing a barrier
> > > on CPUs not running the current process if it can, while
> > > ~MEMBARRIER_PRIVATE may not.  (The latter would be useful for
> > > applications such as system-wide tracing.)  That they're currently both
> > > implemented the same way doesn't mean they're semantically equivalent.
> > 
> > Sure; but why bother with pointless fluff like that? We can always
> > introduce the private flag if and when it starts to make sense having
> > it.
> 
> Without the expedited implementation, the only usefulness of the
> private flag is to skip synchronize_sched() if called from a
> single-threaded process.
> 
> We could easily argue that if a process is using sys_membarrier in
> the first place, it's very likely that it is multithreaded. So I
> agree that we can drop the flag for now, and add it later on,
> e.g. when adding the expedited mode.
> 
> I am tempted to leave the "flags" argument in place though, along
> with the "MEMBARRIER_QUERY" flag. Thoughts ?

You should definitely *always* supply a flags argument with any new
syscall, even if you have no flags yet.

As for QUERY, I assume that exists because the more expensive forms of
barriers (e.g. expedited) are sufficiently invasive that you don't want
to trigger one when not needed just to test if they work?  If so, then
yeah, having that flag seems fine.

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