linux-kernel - Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (v5)

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: <1263406071.3874.16.camel@entropy>
Date:	Wed, 13 Jan 2010 10:07:51 -0800
From:	Nicholas Miell <nmiell@...cast.net>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org,
	josh@...htriplett.org, tglx@...utronix.de, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, laijs@...fujitsu.com, dipankar@...ibm.com
Subject: Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory
 barrier (v5)

On Wed, 2010-01-13 at 09:38 -0500, Mathieu Desnoyers wrote:
> * Nicholas Miell (nmiell@...cast.net) wrote:
> > On Tue, 2010-01-12 at 21:31 -0800, Paul E. McKenney wrote:
> > > Why is it OK to ignore the developer's request for an expedited
> > > membarrer()?  The guy who expected the syscall to complete in a few
> > > microseconds might not be so happy to have it take many milliseconds.
> > > By the same token, the guy who specified non-expedited so as to minimally
> > > disturb other threads in the system might not be so happy to see them
> > > all be IPIed for no good reason.  ;-)
> > > 
> > > 							Thanx, Paul
> > 
> > Because the behavior is still correct, even if it is slower than you'd
> > expect. It doesn't really matter where the expedited flag goes, though,
> > because every future kernel will understand it.
> 
> 16ms vs few µs is such a huge performance difference that it's barely
> adequate to say that the behavior is still correct, but we definitely
> cannot say it is unchanged. It can really render some applications
> unusable.
> 
> If, for some reason, the expedited version of the system call happens to
> be unimplemented, we should return -EINVAL, so the application can deal
> with it in the approproate way (which could be, for instance, to use a
> fall-back doing memory barriers on the RCU read-side).
> 
> But I don't see any reason for not implementing the expedited version
> properly in the first place.
> 

You're focusing on the least important detail of the proposal. It
doesn't matter whether the expedited flag is compat flag or an incompat
flag, because every version of kernel that ever has the membarrier
system call will know what it means, and even if for some reason it
doesn't implement expedited membarriers, it will still be able to
recognize the flag and return an error.

The whole point of compat and incompat flags is that it allows new
applications to run on old kernels and either work or fail as
appropriate, depending on whether the new features they're using must be
implemented or can be silently ignored.

-- 
Nicholas Miell <nmiell@...cast.net>

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