LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au> To: "Michal Suchánek" <msuchanek@suse.de>, "Nicholas Piggin" <npiggin@gmail.com> Cc: "Kate Stewart" <kstewart@linuxfoundation.org>, "Madhavan Srinivasan" <maddy@linux.vnet.ibm.com>, "Mahesh Salgaonkar" <mahesh@linux.vnet.ibm.com>, "Al Viro" <viro@zeniv.linux.org.uk>, "Paul Mackerras" <paulus@samba.org>, "Michael Neuling" <mikey@neuling.org>, "Bryant G. Ly" <bryantly@linux.vnet.ibm.com>, "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>, "Daniel Axtens" <dja@axtens.net>, "Cédric Le Goater" <clg@kaod.org>, "David Gibson" <david@gibson.dropbear.id.au>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org, "Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>, "Masami Hiramatsu" <mhiramat@kernel.org>, "Andrew Donnellan" <andrew.donnellan@au1.ibm.com>, "Philippe Ombredanne" <pombredanne@nexb.com>, "Joe Perches" <joe@perches.com>, "Oliver O'Halloran" <oohall@gmail.com>, "Andrew Morton" <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, "Tobin C. Harding" <me@tobin.cc> Subject: Re: [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry Date: Sat, 17 Mar 2018 00:28:42 +1100 [thread overview] Message-ID: <873710i1yt.fsf@concordia.ellerman.id.au> (raw) In-Reply-To: <20180316101549.31238bdf@naga.suse.cz> Hi Michal, Thanks for working on this series in the absence of any documentation. Michal Suchánek <msuchanek@suse.de> writes: > On Fri, 16 Mar 2018 15:18:23 +1000 > Nicholas Piggin <npiggin@gmail.com> wrote: > >> On Thu, 15 Mar 2018 20:15:52 +0100 >> Michal Suchanek <msuchanek@suse.de> wrote: >> >> > On powerpc syscall entry is done in assembly so patch in an explicit >> > barrier_nospec. >> >> Same comment as Linus for this -- the barriers are before the branch >> here, so is it possible the branch instruction can be speculative >> while the index is used to load the syscall table? > > As far as I understand barriers they separate code before the barrier > and code after the barrier. > > So inserting barrier_nospec after cmpldi means that the result of the > cmpldi has to be known before any instruction following barrier_nospec > that depends on the result can be executed. That would make sense, but I don't think that's how the barrier's been defined. I don't have a formal spec for it (yet), but what I do have indicates it only orders older branches vs future instructions. > However, you have probably knowledge of the powerpc implementation of > the barrier so if the semantic is actually different then please > enlighten me. We have some knowledge, but only some :) It's not necessarily implemented the same way on each chip revision, so it's not entirely clear what the formal semantics will be vs what we are seeing in current implementations. But I think it's safe to say it should always go after the branch that might be speculatively executed. Will try and get some better documentation for you. cheers
next prev parent reply other threads:[~2018-03-16 13:28 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-13 18:32 [PATCH RFC 0/8] powerpc barrier_nospec Michal Suchanek 2018-03-13 18:32 ` [PATCH RFC 1/8] powerpc: Add barrier_nospec Michal Suchanek 2018-03-13 20:01 ` Peter Zijlstra 2018-03-15 19:15 ` [PATCH RFC rebase 0/9] powerpc barrier_nospec Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 1/9] powerpc: Add barrier_nospec Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 2/9] powerpc: Use barrier_nospec in copy_from_user Michal Suchanek 2018-03-15 21:37 ` Linus Torvalds 2018-03-16 13:22 ` Michael Ellerman 2018-03-15 19:15 ` [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry Michal Suchanek 2018-03-16 5:18 ` Nicholas Piggin 2018-03-16 9:15 ` Michal Suchánek 2018-03-16 10:46 ` Nicholas Piggin 2018-03-16 13:28 ` Michael Ellerman [this message] 2018-03-16 17:08 ` Linus Torvalds 2018-03-15 19:15 ` [PATCH RFC rebase 4/9] powerpc/64s: Use barrier_nospec in RFI_FLUSH_SLOT Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 5/9] powerpc/64s: Add support for ori barrier_nospec patching Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 6/9] powerpc/64: Patch barrier_nospec in modules Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 7/9] powerpc/64: barrier_nospec: Add debugfs trigger Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 8/9] powerpc/64s: barrier_nospec: Add hcall triggerr Michal Suchanek 2018-03-15 19:15 ` [PATCH RFC rebase 9/9] powerpc/64: barrier_nospec: Add commandline trigger Michal Suchanek 2018-03-23 15:59 ` Diana Madalina Craciun 2018-03-16 8:08 ` [PATCH RFC rebase 0/9] powerpc barrier_nospec Greg Kroah-Hartman 2018-03-16 9:31 ` Michal Suchánek 2018-03-13 18:33 ` [PATCH RFC 2/8] powerpc: Use barrier_nospec in copy_from_user Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 3/8] powerpc/64: Use barrier_nospec in syscall entry Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 4/8] powerpc/64s: Add support for ori barrier_nospec Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 5/8] powerpc/64: Patch barrier_nospec in modules Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 6/8] powerpc/64: barrier_nospec: Add debugfs trigger Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 7/8] powerpc/64s: barrier_nospec: Add hcall triggerr Michal Suchanek 2018-03-13 18:33 ` [PATCH RFC 8/8] powerpc/64: barrier_nospec: Add commandline trigger Michal Suchanek
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=873710i1yt.fsf@concordia.ellerman.id.au \ --to=mpe@ellerman.id.au \ --cc=akpm@linux-foundation.org \ --cc=andrew.donnellan@au1.ibm.com \ --cc=bryantly@linux.vnet.ibm.com \ --cc=clg@kaod.org \ --cc=david@gibson.dropbear.id.au \ --cc=dja@axtens.net \ --cc=gregkh@linuxfoundation.org \ --cc=joe@perches.com \ --cc=kstewart@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=maddy@linux.vnet.ibm.com \ --cc=mahesh@linux.vnet.ibm.com \ --cc=me@tobin.cc \ --cc=mhiramat@kernel.org \ --cc=mikey@neuling.org \ --cc=msuchanek@suse.de \ --cc=naveen.n.rao@linux.vnet.ibm.com \ --cc=npiggin@gmail.com \ --cc=oohall@gmail.com \ --cc=paulus@samba.org \ --cc=pombredanne@nexb.com \ --cc=sergey.senozhatsky@gmail.com \ --cc=viro@zeniv.linux.org.uk \ /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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).