linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
       [not found]           ` <20201028232001.pp7erdwft7oyt2xm@ast-mbp.dhcp.thefacebook.com>
@ 2020-10-29  2:57             ` Arvind Sankar
  2020-10-29 20:31               ` Segher Boessenkool
  0 siblings, 1 reply; 3+ messages in thread
From: Arvind Sankar @ 2020-10-29  2:57 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Ard Biesheuvel, Linux Kernel Mailing List,
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	Arnd Bergmann, Nick Desaulniers, Arvind Sankar, Randy Dunlap,
	Josh Poimboeuf, Thomas Gleixner, Alexei Starovoitov,
	Daniel Borkmann, Peter Zijlstra, Geert Uytterhoeven, Kees Cook,
	linux-toolchains

On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 29, 2020 at 12:10:52AM +0100, Ard Biesheuvel wrote:
> > On Wed, 28 Oct 2020 at 23:59, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Oct 28, 2020 at 11:15:04PM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 28 Oct 2020 at 22:39, Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Wed, Oct 28, 2020 at 06:15:05PM +0100, Ard Biesheuvel wrote:
> > > > > > Commit 3193c0836 ("bpf: Disable GCC -fgcse optimization for
> > > > > > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> > > > > > function scope __attribute__((optimize("-fno-gcse"))), to disable a
> > > > > > GCC specific optimization that was causing trouble on x86 builds, and
> > > > > > was not expected to have any positive effect in the first place.
> > > > > >
> > > > > > However, as the GCC manual documents, __attribute__((optimize))
> > > > > > is not for production use, and results in all other optimization
> > > > > > options to be forgotten for the function in question. This can
> > > > > > cause all kinds of trouble, but in one particular reported case,
> > > > > > it causes -fno-asynchronous-unwind-tables to be disregarded,
> > > > > > resulting in .eh_frame info to be emitted for the function.
> > > > > >
> > > > > > This reverts commit 3193c0836, and instead, it disables the -fgcse
> > > > > > optimization for the entire source file, but only when building for
> > > > > > X86 using GCC with CONFIG_BPF_JIT_ALWAYS_ON disabled. Note that the
> > > > > > original commit states that CONFIG_RETPOLINE=n triggers the issue,
> > > > > > whereas CONFIG_RETPOLINE=y performs better without the optimization,
> > > > > > so it is kept disabled in both cases.
> > > > > >
> > > > > > Fixes: 3193c0836 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()")
> > > > > > Link: https://lore.kernel.org/lkml/CAMuHMdUg0WJHEcq6to0-eODpXPOywLot6UD2=GFHpzoj_hCoBQ@mail.gmail.com/
> > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > > ---
> > > > > >  include/linux/compiler-gcc.h   | 2 --
> > > > > >  include/linux/compiler_types.h | 4 ----
> > > > > >  kernel/bpf/Makefile            | 6 +++++-
> > > > > >  kernel/bpf/core.c              | 2 +-
> > > > > >  4 files changed, 6 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > > > > > index d1e3c6896b71..5deb37024574 100644
> > > > > > --- a/include/linux/compiler-gcc.h
> > > > > > +++ b/include/linux/compiler-gcc.h
> > > > > > @@ -175,5 +175,3 @@
> > > > > >  #else
> > > > > >  #define __diag_GCC_8(s)
> > > > > >  #endif
> > > > > > -
> > > > > > -#define __no_fgcse __attribute__((optimize("-fno-gcse")))
> > > > >
> > > > > See my reply in the other thread.
> > > > > I prefer
> > > > > -#define __no_fgcse __attribute__((optimize("-fno-gcse")))
> > > > > +#define __no_fgcse __attribute__((optimize("-fno-gcse,-fno-omit-frame-pointer")))
> > > > >
> > > > > Potentially with -fno-asynchronous-unwind-tables.
> > > > >
> > > >
> > > > So how would that work? arm64 has the following:
> > > >
> > > > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables
> > > >
> > > > ifeq ($(CONFIG_SHADOW_CALL_STACK), y)
> > > > KBUILD_CFLAGS += -ffixed-x18
> > > > endif
> > > >
> > > > and it adds -fpatchable-function-entry=2 for compilers that support
> > > > it, but only when CONFIG_FTRACE is enabled.
> > >
> > > I think you're assuming that GCC drops all flags when it sees __attribute__((optimize)).
> > > That's not the case.
> > >
> > 
> > So which flags does it drop, and which doesn't it drop? Is that
> > documented somewhere? Is that the same for all versions of GCC?
> > 
> > > > Also, as Nick pointed out, -fno-gcse does not work on Clang.
> > >
> > > yes and what's the point?
> > > #define __no_fgcse is GCC only. clang doesn't need this workaround.
> > >
> > 
> > Ah ok, that's at least something.
> > 
> > > > Every architecture will have a different set of requirements here. And
> > > > there is no way of knowing which -f options are disregarded when you
> > > > use the function attribute.
> > > >
> > > > So how on earth are you going to #define __no-fgcse correctly for
> > > > every configuration imaginable?
> > > >
> > > > > __attribute__((optimize("")) is not as broken as you're claiming to be.
> > > > > It has quirky gcc internal logic, but it's still widely used
> > > > > in many software projects.
> > > >
> > > > So it's fine because it is only a little bit broken? I'm sorry, but
> > > > that makes no sense whatsoever.
> > > >
> > > > If you insist on sticking with this broken construct, can you please
> > > > make it GCC/x86-only at least?
> > >
> > > I'm totally fine with making
> > > #define __no_fgcse __attribute__((optimize("-fno-gcse,-fno-omit-frame-pointer")))
> > > to be gcc+x86 only.
> > > I'd like to get rid of it, but objtool is not smart enough to understand
> > > generated asm without it.
> > 
> > I'll defer to the x86 folks to make the final call here, but I would
> > be perfectly happy doing
> > 
> > index d1e3c6896b71..68ddb91fbcc6 100644
> > --- a/include/linux/compiler-gcc.h
> > +++ b/include/linux/compiler-gcc.h
> > @@ -176,4 +176,6 @@
> >  #define __diag_GCC_8(s)
> >  #endif
> > 
> > +#ifdef CONFIG_X86
> >  #define __no_fgcse __attribute__((optimize("-fno-gcse")))
> > +#endif
> 
> If you're going to submit this patch could you please add
> ,-fno-omit-frame-pointer
> to the above as well?
> 
> > and end the conversation here, because I honestly cannot wrap my head
> > around the fact that you are willing to work around an x86 specific
> > objtool shortcoming by arbitrarily disabling some GCC optimization for
> > all architectures, using a construct that may or may not affect other
> > compiler settings in unpredictable ways, where the compiler is being
> > used to compile a BPF language runtime for executing BPF programs
> > inside the kernel.
> > 
> > What on earth could go wrong?
> 
> Frankly I'm move worried that -Os will generate incorrect code.
> All compilers have bugs. Kernel has bugs. What can go wrong?

+linux-toolchains. GCC updated the documentation in 7.x to discourage
people from using the optimize attribute.

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=893100c3fa9b3049ce84dcc0c1a839ddc7a21387

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
  2020-10-29  2:57             ` [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE Arvind Sankar
@ 2020-10-29 20:31               ` Segher Boessenkool
  2020-10-29 22:13                 ` Ard Biesheuvel
  0 siblings, 1 reply; 3+ messages in thread
From: Segher Boessenkool @ 2020-10-29 20:31 UTC (permalink / raw)
  To: Arvind Sankar
  Cc: Alexei Starovoitov, Ard Biesheuvel, Linux Kernel Mailing List,
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	Arnd Bergmann, Nick Desaulniers, Randy Dunlap, Josh Poimboeuf,
	Thomas Gleixner, Alexei Starovoitov, Daniel Borkmann,
	Peter Zijlstra, Geert Uytterhoeven, Kees Cook, linux-toolchains

On Wed, Oct 28, 2020 at 10:57:45PM -0400, Arvind Sankar wrote:
> On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote:
> > All compilers have bugs. Kernel has bugs. What can go wrong?

Heh.

> +linux-toolchains. GCC updated the documentation in 7.x to discourage
> people from using the optimize attribute.
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=893100c3fa9b3049ce84dcc0c1a839ddc7a21387

https://patchwork.ozlabs.org/project/gcc/patch/20151213081911.GA320@x4/
has all the discussion around that GCC patch.


Segher

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
  2020-10-29 20:31               ` Segher Boessenkool
@ 2020-10-29 22:13                 ` Ard Biesheuvel
  0 siblings, 0 replies; 3+ messages in thread
From: Ard Biesheuvel @ 2020-10-29 22:13 UTC (permalink / raw)
  To: Segher Boessenkool
  Cc: Arvind Sankar, Alexei Starovoitov, Linux Kernel Mailing List,
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	open list:BPF JIT for MIPS (32-BIT AND 64-BIT),
	Arnd Bergmann, Nick Desaulniers, Randy Dunlap, Josh Poimboeuf,
	Thomas Gleixner, Alexei Starovoitov, Daniel Borkmann,
	Peter Zijlstra, Geert Uytterhoeven, Kees Cook, linux-toolchains

On Thu, 29 Oct 2020 at 21:35, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Wed, Oct 28, 2020 at 10:57:45PM -0400, Arvind Sankar wrote:
> > On Wed, Oct 28, 2020 at 04:20:01PM -0700, Alexei Starovoitov wrote:
> > > All compilers have bugs. Kernel has bugs. What can go wrong?
>
> Heh.
>
> > +linux-toolchains. GCC updated the documentation in 7.x to discourage
> > people from using the optimize attribute.
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=893100c3fa9b3049ce84dcc0c1a839ddc7a21387
>
> https://patchwork.ozlabs.org/project/gcc/patch/20151213081911.GA320@x4/
> has all the discussion around that GCC patch.
>

For everyone's convenience, let me reproduce here how the GCC
developers describe this attribute on their wiki [0]:

"""
Currently (2015), this attribute is known to have several critical
bugs (PR37565, PR63401, PR60580, PR50782). Using it may produce not
effect at all or lead to wrong-code.

Quoting one GCC maintainer: "I consider the optimize attribute code
seriously broken and unmaintained (but sometimes useful for debugging
- and only that)." source

Unfortunately, the people who added it are either not working on GCC
anymore or not interested in fixing it. Do not try to guess how it is
supposed to work by trial-and-error. There is not a list of options
that are safe to use or known to be broken. Bug reports about the
optimize attribute being broken will probably be closed as WONTFIX
(PR59262), thus it is not worth to open new ones. If it works for you
for a given version of GCC, it doesn't mean it will work on a
different machine or a different version.

The only realistic choices are to not use it, to use it and accept its
brokenness (current or future one, since it is unmaintained), or join
GCC and fix it (perhaps motivating other people along the way to join
your effort).
"""

[0] https://gcc.gnu.org/wiki/FAQ#optimize_attribute_broken

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-29 22:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20201028171506.15682-1-ardb@kernel.org>
     [not found] ` <20201028171506.15682-2-ardb@kernel.org>
     [not found]   ` <20201028213903.fvdjydadqt6tx765@ast-mbp.dhcp.thefacebook.com>
     [not found]     ` <CAMj1kXFHcM-Jb+MwsLtB4NMUmMyAGGLeNGNLC9vTATot3NJLrA@mail.gmail.com>
     [not found]       ` <20201028225919.6ydy3m2u4p7x3to7@ast-mbp.dhcp.thefacebook.com>
     [not found]         ` <CAMj1kXG8PmvO6bLhGXPWtzKMnAsip2WDa-qdrd+kFfr30sd8-A@mail.gmail.com>
     [not found]           ` <20201028232001.pp7erdwft7oyt2xm@ast-mbp.dhcp.thefacebook.com>
2020-10-29  2:57             ` [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE Arvind Sankar
2020-10-29 20:31               ` Segher Boessenkool
2020-10-29 22:13                 ` Ard Biesheuvel

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