linux-kernel - Re: perf test LLVM & clang 6 failing

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2017 13:57:56 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Yonghong Song <yhs@...com>, Daniel Borkmann <daniel@...earbox.net>,
        Wang Nan <wangnan0@...wei.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Matthias Kaehlcke <mka@...omium.org>
Subject: Re: perf test LLVM & clang 6 failing

On Mon, Nov 27, 2017 at 04:34:25PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 27, 2017 at 11:11:56AM -0800, Yonghong Song escreveu:
> > On 11/27/17 9:04 AM, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
> > > > [ +Yonghong ]
> > > 
> > > + Josh
> > > > On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
> > > > > FYI, just noticed, recently updated clang to version 6, from its
> > > > > upstream git repo.
> > > > 
> > > > Do you recall what was your LLVM version prior to this where it was
> > > > working fine? (Wild guess from below would be the BPF inline asm
> > > > support that was added recently to LLVM (2865ab6996) vs asm() used
> > > > in headers included in the stdin header causing trouble due to arch
> > > > mixup?)
> > > 
> > > So, if I go to the cset just before:
> > > 
> > > commit f5caf621ee357279e759c0911daf6d55c7d36f03
> > > Author: Josh Poimboeuf <jpoimboe@...hat.com>
> > > Date:   Wed Sep 20 16:24:33 2017 -0500
> > > 
> > >      x86/asm: Fix inline asm call constraints for Clang
> > > ---
> > > 
> > > 'perf test LLVM' works again:
> > > 
> > > [root@...et ~]# perf test LLVM
> > > 37: LLVM search and compile                               :
> > > 37.1: Basic BPF llvm compile                              : Ok
> > > 37.2: kbuild searching                                    : Ok
> > > 37.3: Compile source for BPF prologue generation          : Ok
> > > 37.4: Compile source for BPF relocation                   : Ok
> > > [root@...et ~]#
> > > 
> > > I.e. 'perf test LLVM' built from what is in my acme/perf/urgent branch,
> > > targetted to v4.15, uses kernel headers and if I go to just before
> > > f5caf621ee, it works again, both with clang from fedora26 (4.0.1) and
> > > with 6.0, built from sources.
> > 
> > This patch introduced a module level inline assembly.
> > 
> > ...
> > --- a/arch/x86/include/asm/asm.h
> > +++ b/arch/x86/include/asm/asm.h
> > @@ -132,4 +132,15 @@
> >  /* For C file, we already have NOKPROBE_SYMBOL macro */
> >  #endif
> > 
> > +#ifndef __ASSEMBLY__
> > +/*
> > + * This output constraint should be used for any inline asm which has a
> > "call"
> > + * instruction.  Otherwise the asm may be inserted before the frame pointer
> > + * gets set up by the containing function.  If you forget to do this,
> > objtool
> > + * may print a "call without frame pointer save/setup" warning.
> > + */
> > +register unsigned int __asm_call_sp asm("esp");
> > +#define ASM_CALL_CONSTRAINT "+r" (__asm_call_sp)
> > +#endif
> > ...
> > 
> > This will cause "clang ... -target bpf ..." failure since 4.0 does not have
> > bpf inline asm support and 6.0 does not recognize the register 'esp'.
> 
> Ok, explains the problem then, Josh, ideas on how to proceed here?

The original change to add the global inline asm:

  5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")

was done to support clang in the first place.  Before that change, a
clang-built kernel didn't even boot.  So I'm a bit perplexed by the fact
that this change would be causing clang problems, since it was done to
fix clang in the first place.

Adding Andrey and Matthias, maybe they can help clarify things.

-- 
Josh