LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: "Michal Suchánek" <msuchanek@suse.de>
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>,
	"Anton Blanchard" <anton@ozlabs.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>
Subject: Re: [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry
Date: Fri, 16 Mar 2018 20:46:47 +1000	[thread overview]
Message-ID: <20180316204647.68417bc5@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20180316101549.31238bdf@naga.suse.cz>

On Fri, 16 Mar 2018 10:15:49 +0100
Michal Suchánek <msuchanek@suse.de> wrote:

> Hello,
> 
> 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. 
> 
> In many cases it is useful to put the barrier after a branch. It allows
> the compiler to speculate on the computed value at compile time and if
> it is constrained optimize out the branch. It may also result in the
> need to include many barriers and less readable code.
> 
> However, you have probably knowledge of the powerpc implementation of
> the barrier so if the semantic is actually different then please
> enlighten me.

I actually don't. I'm assuming we should be able to say that no previous
instruction is speculative when a subsequent one is executed.

But the branch instruction itself that is speculated, not the compare.

Usually even if all sources are ready, the pipeline may take in some
cycles after a branch, before that branch can finish executing and
squash speculation if it was wrong. Perhaps there is only a couple of
cycles of instructions that get a chance to reach execution units and
disturb any caches, but still there could be some window and I don't
think we would have architectural gurantees on that.

I'll try to ask around and see if there's any documentation we can
give you yet.

Thanks,
Nick

  reply	other threads:[~2018-03-16 10:46 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 [this message]
2018-03-16 13:28             ` Michael Ellerman
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=20180316204647.68417bc5@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=anton@ozlabs.org \
    --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=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=naveen.n.rao@linux.vnet.ibm.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: link
Be 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).