All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
	<netdev@vger.kernel.org>,
	"open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
	<bpf@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Randy Dunlap <rdunlap@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
Date: Thu, 29 Oct 2020 20:22:47 -0700	[thread overview]
Message-ID: <20201030032247.twch6rvnk6ql3zjb@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAKwvOd=Zrza=i54_=H3n2HkmMhg9EJ3Wy0kR5AXTSqBowsQV5g@mail.gmail.com>

On Thu, Oct 29, 2020 at 05:28:11PM -0700, Nick Desaulniers wrote:
> 
> We already know that -fno-asynchronous-unwind-tables get dropped,
> hence this patch.  

On arm64 only. Not on x86

> And we know -fomit-frame-pointer or
> -fno-omit-frame-pointer I guess gets dropped, hence your ask.  

yep. that one is bugged.

> We might not know the full extent which other flags get dropped with the
> optimize attribute, but I'd argue that my list above can all result in
> pretty bad bugs when accidentally omitted (ok, maybe not -fshort-wchar
> or -fmacro-prefix-map, idk what those do) or when mixed with code that

true.
Few month back I've checked that strict-aliasing and no-common flags
from your list are not dropped by this attr in gcc [6789].
I've also checked that no-red-zone and model=kernel preserved as well.

> has different values those flags control.  Searching GCC's bug tracker
> for `__attribute__((optimize` turns up plenty of reports to make me
> think this attribute maybe doesn't work the way folks suspect or
> intend: https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__attribute__%28%28optimize&list_id=283390.

There is a risk.
Is it a footgun? Sure.
Yet. gcc testsuite is using __attribute__((optimize)).
And some of these tests were added _after_ offical gcc doc said that this
attribute is broken.
imo it's like 'beware of the dog' sign.

> There's plenty of folks arguing against the use of the optimize
> attribute in favor of the command line flag.  I urge you to please
> reconsider the request.

ok. Applied this first patch to bpf tree and will get it to Linus soon.
Second patch that is splitting interpreter out because of this mess
is dropped. The effect of gcse on performance is questionable.
iirc some interpreters used to do -fno-gcse to gain performance.

  reply	other threads:[~2020-10-30  3:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 17:15 [PATCH v2 0/2] get rid of GCC __attribute__((optimize)) for BPF Ard Biesheuvel
2020-10-28 17:15 ` [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE Ard Biesheuvel
2020-10-28 21:39   ` Alexei Starovoitov
2020-10-28 22:15     ` Ard Biesheuvel
2020-10-28 22:59       ` Alexei Starovoitov
2020-10-28 23:10         ` Ard Biesheuvel
2020-10-28 23:20           ` Alexei Starovoitov
2020-10-29  2:57             ` Arvind Sankar
2020-10-29 20:31               ` Segher Boessenkool
2020-10-29 22:13                 ` Ard Biesheuvel
2020-10-30  0:28             ` Nick Desaulniers
2020-10-30  3:22               ` Alexei Starovoitov [this message]
2020-10-30  7:51                 ` Ard Biesheuvel
2020-10-29  8:25   ` Geert Uytterhoeven
2020-10-30  0:34   ` Nick Desaulniers
2020-10-28 17:15 ` [PATCH v2 2/2] bpf: move interpreter into separate source file Ard Biesheuvel

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=20201030032247.twch6rvnk6ql3zjb@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=geert@linux-m68k.org \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    /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.