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:	Mon, 11 Jan 2010 22:31:14 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.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,
	"David S. Miller" <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory
 barrier (v3a)

On Mon, 2010-01-11 at 15:52 -0500, Mathieu Desnoyers wrote:

> >  - receiving an IPI implies an mb, or
> 
> So, I think that if we have other concurrent IPI requests sent, we have
> no guarantee that the IPI handler will indeed issue the memory barrier 
> _after_ we added the entry to the list. The list itself is synchronized
> with a spin lock-irqoff, but not with an explicit memory barrier. Or am
> I missing a subtlety here ?

Linus once said ( http://lkml.org/lkml/2009/2/18/145 ) :

"... at least on x86, taking an interrupt should be a serializing 
event, so there should be no reason for anything on the receiving side."

But he also notes that in generic this does not need to be so.

My question was more generic than: is this currently the case for x86,
though, I was wondering if we want this to be true and should therefore
make it so.

However re-reading the referenced discussion I think we might not want
to force it in generic because it might cause unneeded slow-down.

> >  - enter/leave kernelspace implies an mb
> > ?
> 
> On x86, iret is a serializing instruction. However, I haven't found any
> information saying that int 0x80 nor sysenter/sysexit are serializing
> instructions. And there seem to be no explicit mfence in x86 entry_*.S
> (except a 64-bit gs swap workaround). So I'm tempted to answer: no,
> entry/return kernelspace does not seem to imply a mb on x86. 

Right, there's some TIF_flags we can play with, but simply executing the
mb is a much simpler (and clearer) alternative.



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ