linux-kernel - Re: Alternative to signals/sys_membarrier() in liburcu

Open Source and information security mailing list archives

Message-ID: <1243872207.287578.1426193760572.JavaMail.zimbra@efficios.com>
Date:	Thu, 12 Mar 2015 20:56:00 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Michael Sullivan <sully@...lly.net>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	lttng-dev@...ts.lttng.org, Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: Alternative to signals/sys_membarrier() in liburcu

(sorry for re-send, my mail client tricked me into posting HTML
to lkml)

Hi, 

Michael Sullivan proposed a clever hack abusing mprotect() to 
perform the same effect as sys_membarrier() I submitted a few 
years ago ( https://lkml.org/lkml/2010/4/18/15 ). 

At that time, the sys_membarrier implementation was deemed 
technically sound, but there were not enough users of the system call 
to justify its inclusion. 

So far, the number of users of liburcu has increased, but liburcu 
still appears to be the only direct user of sys_membarrier. On this 
front, we could argue that many other system calls have only 
one user: glibc. In that respect, liburcu is quite similar to glibc. 

So the question as it stands appears to be: would you be comfortable 
having users abuse mprotect(), relying on its side-effect of issuing 
a smp_mb() on each targeted CPU for the TLB shootdown, as 
an effective implementation of process-wide memory barrier ? 

Thoughts ? 

Thanks! 

Mathieu 

From: "Michael Sullivan" <sully@...lly.net> 
To: "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com> 
Cc: lttng-dev@...ts.lttng.org 
Sent: Thursday, March 12, 2015 12:04:07 PM 
Subject: Re: [lttng-dev] Alternative to signals/sys_membarrier() in liburcu 

On Thu, Mar 12, 2015 at 10:57 AM, Mathieu Desnoyers < mathieu.desnoyers@...icios.com > wrote: 

Even though it depends on internal behavior not currently specified by mprotect, 
I'd very much like to see the prototype you have, 

I ended up posting my code at https://github.com/msullivan/userspace-rcu/tree/msync-barrier . 
The interesting patch is https://github.com/msullivan/userspace-rcu/commit/04656b468d418efbc5d934ab07954eb8395a7ab0 . 

Quick blog post I wrote about it at http://www.msully.net/blog/2015/02/24/forcing-memory-barriers-on-other-cpus-with-mprotect2/ . 
(I talked briefly about sys_membarrier in the post as best as I could piece together from LKML; if my comment on it is inaccurate I can edit the post.) 

-Michael Sullivan 

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 

_______________________________________________
lttng-dev mailing list
lttng-dev@...ts.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
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/

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