LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Yonghong Song <yhs@fb.com>,
	mingo@kernel.org, torvalds@linux-foundation.org, ast@fb.com,
	daniel@iogearbox.net, linux-kernel@vger.kernel.org,
	x86@kernel.org, netdev@vger.kernel.org, kernel-team@fb.com,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto
Date: Thu, 10 May 2018 08:52:42 -0700	[thread overview]
Message-ID: <20180510155240.5s2fpgm2fwal3jlj@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20180510100634.GZ12217@hirez.programming.kicks-ass.net>

On Thu, May 10, 2018 at 12:06:34PM +0200, Peter Zijlstra wrote:
> On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> 
> > This approach is preferred since the already deployed bcc scripts, or
> > any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> > will continue work with the new kernel without re-compilation and
> > re-deployment.
> 
> So I really hate this and would much rather see the BPF build
> environment changed. It not consistenyly having __BPF__ defined really
> smells like a bug on your end.
> 
> Sometimes you just need to update tools... Is it really too hard to do
> -D__BPF__ in the bpf build process that we need to mollest the kernel
> for it?
> 
> > Note that this is a hack in the kernel to workaround bpf compilation issue.
> > The hack will be removed once clang starts to support asm goto.
> 
> Note that that ^^ already mandates people re-deploy their bpf tools, so
> why is llvm supporting asm-goto a better point to re-deploy than fixing
> a consistent __BPF__ define for the bpf build environment?

This thread has been going for over a month now. Looks like we're starting
to go in circles and what we discussed earlier got lost. To recap:

- this is NOT a bpf issue. libbcc is the first user that got broken
  by commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")

- all other libraries and tools (like fuzzers, static code analyzers, etc)
  that are using clang front-end to process kernel headers are broken too

That makes me wonder what happened with "we do not break user space" rule?

I think the safest course of action would be to partially revert the
offending commit d0266046ad54 which we proposed first.
Since you were concerned that this is somehow will disincentivize clang
folks to add asm-goto support, we agreed to add this __NO_CLANG_BPF_HACK
macro to un-break libbcc at least, so that existing libbcc installations
will continue to work when people upgrade kernels.

The __BPF__ macro is automatically defined by clang when '-target bpf' is used.
This is NOT the case here. libbcc has to use native target when
processing kernel headers.

It happens from time to time that one or the other libbcc script gets
broken by new kernel because kprobe symbol that the script is using
got changed in the recent kernel. That's ok and we deal with this situation
all the time. What's different this time that ALL bcc scripts are broken
because of this commit and we cannot workaround in user space.

  reply	other threads:[~2018-05-10 15:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04  3:31 Yonghong Song
2018-05-10 10:06 ` Peter Zijlstra
2018-05-10 15:52   ` Alexei Starovoitov [this message]
2018-05-10 16:20     ` Borislav Petkov
2018-05-10 17:57       ` Gianluca Borello
2018-05-10 17:58       ` Alexei Starovoitov
2018-05-10 18:16         ` Borislav Petkov
2018-05-10 10:49 ` Borislav Petkov
2018-05-12 16:03 Alexei Starovoitov
2018-05-12 20:30 ` Thomas Gleixner
2018-05-13 17:43   ` Alexei Starovoitov
2018-05-13 18:02     ` Thomas Gleixner

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=20180510155240.5s2fpgm2fwal3jlj@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=yhs@fb.com \
    --subject='Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto' \
    /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

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).