All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility
Date: Wed, 6 May 2020 17:03:57 -0700	[thread overview]
Message-ID: <20200507000357.grprluieqa324v5c@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200506211945.4qhrxqplzmt4ul66@treble>

On Wed, May 06, 2020 at 04:19:45PM -0500, Josh Poimboeuf wrote:
> On Wed, May 06, 2020 at 09:45:01AM -0700, Alexei Starovoitov wrote:
> > On Wed, May 6, 2020 at 8:53 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote:
> > > > As far as workaround I prefer the following:
> > > > From 94bbc27c5a70d78846a5cb675df4cf8732883564 Mon Sep 17 00:00:00 2001
> > > > From: Alexei Starovoitov <ast@kernel.org>
> > > > Date: Tue, 5 May 2020 16:52:41 -0700
> > > > Subject: [PATCH] bpf,objtool: tweak interpreter compilation flags to help objtool
> > > >
> > > > tbd
> > > >
> > > > Fixes: 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()")
> > > > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > > > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > > > Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> > > > ---
> > > >  include/linux/compiler-gcc.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > > > index d7ee4c6bad48..05104c3cc033 100644
> > > > --- a/include/linux/compiler-gcc.h
> > > > +++ b/include/linux/compiler-gcc.h
> > > > @@ -171,4 +171,4 @@
> > > >  #define __diag_GCC_8(s)
> > > >  #endif
> > > >
> > > > -#define __no_fgcse __attribute__((optimize("-fno-gcse")))
> > > > +#define __no_fgcse __attribute__((optimize("-fno-gcse,-fno-omit-frame-pointer")))
> > > > --
> > > > 2.23.0
> > > >
> > > > I've tested it with gcc 8,9,10 and clang 11 with FP=y and with ORC=y.
> > > > All works.
> > > > I think it's safer to go with frame pointers even for ORC=y considering
> > > > all the pain this issue had caused. Even if objtool gets confused again
> > > > in the future __bpf_prog_run() will have frame pointers and kernel stack
> > > > unwinding can fall back from ORC to FP for that frame.
> > > > wdyt?
> > >
> > > It seems dangerous to me.  The GCC manual recommends against it.
> > 
> > The manual can says that it's broken. That won't stop the world from using it.
> > Just google projects that are using it. For example: qt, lz4, unreal engine, etc
> > Telling compiler to disable gcse via flag is a guaranteed way to avoid
> > that optimization that breaks objtool whereas messing with C code is nothing
> > but guess work. gcc can still do gcse.
> 
> But the manual's right, it is broken.  How do you know other important
> flags won't also be stripped?

What flags are you worried about?
I've checked that important things like -mno-red-zone, -fsanitize are preserved.

  reply	other threads:[~2020-05-07  0:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 19:07 [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility Josh Poimboeuf
2020-05-01 19:09 ` Alexei Starovoitov
2020-05-01 19:22   ` Josh Poimboeuf
2020-05-01 19:40     ` Alexei Starovoitov
2020-05-01 19:56       ` Josh Poimboeuf
2020-05-02  3:06         ` Alexei Starovoitov
2020-05-02 19:21           ` Josh Poimboeuf
2020-05-05 17:43             ` Alexei Starovoitov
2020-05-05 17:52               ` Randy Dunlap
2020-05-05 19:14                 ` Alexei Starovoitov
2020-05-05 19:31                   ` Josh Poimboeuf
2020-05-05 18:11               ` Josh Poimboeuf
2020-05-05 19:53                 ` Alexei Starovoitov
2020-05-05 20:28                   ` Josh Poimboeuf
2020-05-05 23:59                     ` Alexei Starovoitov
2020-05-06 15:53                       ` Josh Poimboeuf
2020-05-06 16:45                         ` Alexei Starovoitov
2020-05-06 21:19                           ` Josh Poimboeuf
2020-05-07  0:03                             ` Alexei Starovoitov [this message]
2020-05-07 14:07                               ` Josh Poimboeuf
2020-05-08 22:18                                 ` Alexei Starovoitov

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=20200507000357.grprluieqa324v5c@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.