From: Peter Zijlstra <peterz@infradead.org> To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Avi Kivity <avi@scylladb.com>, Linus Torvalds <torvalds@linux-foundation.org>, Andy Lutomirski <luto@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, linux-api <linux-api@vger.kernel.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Boqun Feng <boqun.feng@gmail.com>, Andrew Hunter <ahh@google.com>, maged michael <maged.michael@gmail.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Dave Watson <davejwatson@fb.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Andrea Parri <parri.andrea@gmail.com>, "Russell King, ARM Linux" <linux@armlinux.org.uk>, Greg Hackmann <ghackmann@google.com>, Will Deacon <will.deacon@arm.com>, David Sehr <sehr@google.com>, x86 <x86@kernel.org> Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration Date: Tue, 14 Nov 2017 17:08:42 +0100 [thread overview] Message-ID: <20171114160842.GH3857@worktop> (raw) In-Reply-To: <20171114160541.GC3165@worktop.lehotels.local> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote: > On Tue, Nov 14, 2017 at 03:17:12PM +0000, Mathieu Desnoyers wrote: > > I've tried to create a small single-threaded self-modifying loop in > > user-space to trigger a trace cache or speculative execution quirk, > > but I have not succeeded yet. I suspect that I would need to know > > more about the internals of the processor architecture to create the > > right stalls that would allow speculative execution to move further > > ahead, and trigger an incoherent execution flow. Ideas on how to > > trigger this would be welcome. > > I thought the whole problem was per definition multi-threaded. > > Single-threaded stuff can't get out of sync with itself; you'll always > observe your own stores. And even if you could, you can always execute a local serializing instruction like CPUID to force things. > And ISTR the JIT scenario being something like the JIT overwriting > previously executed but supposedly no longer used code. And in this > scenario you'd want to guarantee all CPUs observe the new code before > jumping into it. > > The current approach is using mprotect(), except that on a number of > platforms the TLB invalidate from that is not guaranteed to be strong > enough to sync for code changes. > > On x86 the mprotect() should work just fine, since we broadcast IPIs for > the TLB invalidate and the IRET from those will get the things synced up > again (if nothing else; very likely we'll have done a MOV-CR3 which will > of course also have sufficient syncness on it). > > But PowerPC, s390, ARM et al that do TLB invalidates without interrupts > and don't guarantee their TLB invalidate sync against execution units > are left broken by this scheme. >
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> To: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> Cc: Avi Kivity <avi-VrcmuVmyx1hWk0Htik3J/w@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-api <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>, Boqun Feng <boqun.feng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Andrew Hunter <ahh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, maged michael <maged.michael-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>, Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>, Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>, Dave Watson <davejwatson-b10kYP2dOMg@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>, Andrea Parri <parri.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "Russell King, ARM Linux" <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>, Greg Hackmann <ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration Date: Tue, 14 Nov 2017 17:08:42 +0100 [thread overview] Message-ID: <20171114160842.GH3857@worktop> (raw) In-Reply-To: <20171114160541.GC3165-IIpfhp3q70x9+YH6RuovlLjjLBE8jN/0@public.gmane.org> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote: > On Tue, Nov 14, 2017 at 03:17:12PM +0000, Mathieu Desnoyers wrote: > > I've tried to create a small single-threaded self-modifying loop in > > user-space to trigger a trace cache or speculative execution quirk, > > but I have not succeeded yet. I suspect that I would need to know > > more about the internals of the processor architecture to create the > > right stalls that would allow speculative execution to move further > > ahead, and trigger an incoherent execution flow. Ideas on how to > > trigger this would be welcome. > > I thought the whole problem was per definition multi-threaded. > > Single-threaded stuff can't get out of sync with itself; you'll always > observe your own stores. And even if you could, you can always execute a local serializing instruction like CPUID to force things. > And ISTR the JIT scenario being something like the JIT overwriting > previously executed but supposedly no longer used code. And in this > scenario you'd want to guarantee all CPUs observe the new code before > jumping into it. > > The current approach is using mprotect(), except that on a number of > platforms the TLB invalidate from that is not guaranteed to be strong > enough to sync for code changes. > > On x86 the mprotect() should work just fine, since we broadcast IPIs for > the TLB invalidate and the IRET from those will get the things synced up > again (if nothing else; very likely we'll have done a MOV-CR3 which will > of course also have sufficient syncness on it). > > But PowerPC, s390, ARM et al that do TLB invalidates without interrupts > and don't guarantee their TLB invalidate sync against execution units > are left broken by this scheme. >
next prev parent reply other threads:[~2017-11-14 16:09 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-10 21:12 [RFC PATCH 0/2] x86: Fix missing core serialization on migration Mathieu Desnoyers 2017-11-10 21:12 ` Mathieu Desnoyers 2017-11-10 21:12 ` [RFC PATCH 1/2] x86: Introduce sync_core_before_usermode Mathieu Desnoyers 2017-11-10 21:12 ` Mathieu Desnoyers 2017-11-10 21:12 ` [RFC PATCH 2/2] Fix: x86: Add missing core serializing instruction on migration Mathieu Desnoyers 2017-11-10 21:12 ` Mathieu Desnoyers 2017-11-10 21:36 ` [RFC PATCH 0/2] x86: Fix missing core serialization " Linus Torvalds 2017-11-10 21:36 ` Linus Torvalds 2017-11-10 21:57 ` Mathieu Desnoyers 2017-11-10 21:57 ` Mathieu Desnoyers 2017-11-10 22:12 ` Linus Torvalds 2017-11-10 22:12 ` Linus Torvalds 2017-11-13 16:56 ` Mathieu Desnoyers 2017-11-13 16:56 ` Mathieu Desnoyers 2017-11-13 17:14 ` Linus Torvalds 2017-11-13 17:14 ` Linus Torvalds 2017-11-14 14:53 ` Avi Kivity 2017-11-14 14:53 ` Avi Kivity 2017-11-14 15:17 ` Mathieu Desnoyers 2017-11-14 15:17 ` Mathieu Desnoyers 2017-11-14 15:42 ` Avi Kivity 2017-11-14 15:42 ` Avi Kivity 2017-11-14 16:05 ` Peter Zijlstra 2017-11-14 16:05 ` Peter Zijlstra 2017-11-14 16:08 ` Peter Zijlstra [this message] 2017-11-14 16:08 ` Peter Zijlstra 2017-11-14 16:49 ` Mathieu Desnoyers 2017-11-14 16:49 ` Mathieu Desnoyers 2017-11-14 17:03 ` Avi Kivity 2017-11-14 17:03 ` Avi Kivity 2017-11-14 17:10 ` Mathieu Desnoyers 2017-11-14 17:10 ` Mathieu Desnoyers 2017-11-14 17:31 ` Linus Torvalds 2017-11-14 17:31 ` Linus Torvalds 2017-11-14 16:10 ` Andy Lutomirski 2017-11-14 16:10 ` Andy Lutomirski 2017-11-14 16:13 ` Thomas Gleixner 2017-11-14 16:13 ` Thomas Gleixner 2017-11-14 16:16 ` Andy Lutomirski 2017-11-14 16:16 ` Andy Lutomirski 2017-11-14 16:31 ` Peter Zijlstra 2017-11-14 16:31 ` Peter Zijlstra 2017-11-14 17:17 ` Daniel Bristot de Oliveira 2017-11-14 17:17 ` Daniel Bristot de Oliveira 2017-11-14 17:40 ` Peter Zijlstra 2017-11-14 17:40 ` Peter Zijlstra 2017-11-14 18:01 ` Daniel Bristot de Oliveira 2017-11-14 18:01 ` Daniel Bristot de Oliveira 2017-11-14 18:17 ` Peter Zijlstra 2017-11-14 18:17 ` Peter Zijlstra 2017-11-14 18:24 ` Daniel Bristot de Oliveira 2017-11-14 18:24 ` Daniel Bristot de Oliveira
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171114160842.GH3857@worktop \ --to=peterz@infradead.org \ --cc=ahh@google.com \ --cc=avi@scylladb.com \ --cc=benh@kernel.crashing.org \ --cc=boqun.feng@gmail.com \ --cc=davejwatson@fb.com \ --cc=ghackmann@google.com \ --cc=hpa@zytor.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=luto@kernel.org \ --cc=maged.michael@gmail.com \ --cc=mathieu.desnoyers@efficios.com \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=parri.andrea@gmail.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=paulus@samba.org \ --cc=sehr@google.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.