[PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

Michael Ellerman mpe at ellerman.id.au
Sat Mar 17 00:28:42 AEDT 2018


Hi Michal,

Thanks for working on this series in the absence of any documentation.

Michal Suchánek <msuchanek at suse.de> writes:
> On Fri, 16 Mar 2018 15:18:23 +1000
> Nicholas Piggin <npiggin at gmail.com> wrote:
>
>> On Thu, 15 Mar 2018 20:15:52 +0100
>> Michal Suchanek <msuchanek at 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


More information about the Linuxppc-dev mailing list