archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Nick Desaulniers <>
Cc: Borislav Petkov <>, Arnd Bergmann <>,
	Arvind Sankar <>,
	Kalle Valo <>,
	linux-wireless <>,
	"" <>,
	"the arch/x86 maintainers" <>,
	Kees Cook <>,
	Thomas Gleixner <>
Subject: Re: gcc-10: kernel stack is corrupted and fails to boot
Date: Wed, 13 May 2020 19:20:26 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, May 13, 2020 at 5:51 PM Nick Desaulniers
<> wrote:
> Are you sure LTO treats empty asm statements differently than full
> memory barriers in regards to preventing tail calls?

It had better.

At link-time, there is nothing left of an empty asm statement. So by
the time the linker runs, it only sees

    call xyz

in the object code. At that point, it's somewhat reasonable for any
link-time optimizer (or an optimizing assembler, for that matter) to
say "I'll just turn that sequence into a simple 'jmp xyz' instead".

Now, don't get me wrong - I'm not convinced any existing LTO does
that. But I'd also not be shocked by something like that.

In contrast, if it's a real mb(), the linker won't see just a
'call+ret" sequence. It will see something like

    call xyz

(ok, the mfence may actually be something else, and we'll have a label
on it and an alternatives table pointing to it, but the point is,
unlike an empty asm, there's something _there_).

Now, if the linker turns that 'call' into a 'jmp', the linker is just
plain buggy.

See the difference?

> The TL;DR of the very long thread is that
> is a proper fix, on
> the GCC side.  Adding arbitrary empty asm statements to work around
> it? Hacks.  Full memory barriers? Hacks.


A compiler person might call it a "hack". But said compiler person
will be _wrong_.

An intelligent developer knows that it will take years for compilers
to give us all the infrastructure we need, and even then the compiler
won't actually give us everything - and people will be using the old
compilers for years anyway.

That's why inline asm's exist. They are the escape from the excessive
confines of "let's wait for the compiler person to solve this for us"
- which they'll never do completely anyway.

It's a bit like unsafe C type casts and allowing people to write
"non-portable code". Some compiler people will say that it's bad, and
unsafe. Sure, it can be unsafe, but the point is that it allows you to
do things that aren't necessarily _possible_ to do in an overly
restrictive language.

Sometimes you need to break the rules.

There's a reason everybody writes library routines in "unsafe"
languages like C. Because you need those kinds of escapes in order to
actually do something like a memory allocator etc.

And that's also why we have inline asm - because the compiler will
never know everything or be able to generate code for everything
people wants to do.

And anybody that _thinks_ that the compiler will always know better
and should be in complete control shouldn't be working on compilers.
They should probably be repeating kindergarten, sitting in a corner
eating paste with their friends.

So no. Using inline asms to work around the compiler not understanding
what is going on isn't a "hack". It's the _point_ of inline asm.

Is it perfect? No. But it's not like there are many alternatives.


  reply	other threads:[~2020-05-14  2:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09 12:06 [PATCH net-next 1/2] ath10k: fix gcc-10 zero-length-bounds warnings Arnd Bergmann
2020-05-09 12:06 ` [PATCH net-next 2/2] ath10k: fix ath10k_pci struct layout Arnd Bergmann
2020-05-11 12:05   ` Kalle Valo
2020-05-11 12:17     ` Kalle Valo
2020-05-11 12:39       ` Arnd Bergmann
2020-05-13  6:50       ` gcc-10: kernel stack is corrupted and fails to boot Kalle Valo
2020-05-13  8:49         ` Arnd Bergmann
2020-05-13 12:45           ` Kalle Valo
2020-05-13 13:45             ` Arnd Bergmann
2020-05-13 15:31               ` Kalle Valo
2020-05-13 16:00                 ` Arnd Bergmann
2020-05-13 16:07                   ` David Laight
2020-05-14  9:13                 ` Harald Arnesen
2020-05-13 15:48         ` Arvind Sankar
2020-05-13 21:28           ` Arnd Bergmann
2020-05-13 21:41             ` Borislav Petkov
2020-05-13 21:49               ` Arnd Bergmann
2020-05-13 22:20                 ` Borislav Petkov
2020-05-13 22:51                   ` Arvind Sankar
2020-05-13 23:13                   ` Linus Torvalds
2020-05-13 23:36                     ` Borislav Petkov
2020-05-14  0:11                       ` Linus Torvalds
2020-05-14  0:51                         ` Nick Desaulniers
2020-05-14  2:20                           ` Linus Torvalds [this message]
2020-05-14  3:50                             ` Andy Lutomirski
     [not found]                               ` <>
2020-05-14  5:22                                 ` Arvind Sankar
2020-05-14  8:40                                   ` Arnd Bergmann
2020-05-14 13:27                                     ` [PATCH] x86: Fix early boot crash on gcc-10, third try Borislav Petkov
2020-05-14 14:45                                       ` Kalle Valo
2020-05-14 15:50                                     ` gcc-10: kernel stack is corrupted and fails to boot Arvind Sankar
2020-05-14  8:11                             ` David Laight
2020-05-13 23:07                 ` Linus Torvalds
2020-05-09 15:48 ` [PATCH net-next 1/2] ath10k: fix gcc-10 zero-length-bounds warnings Gustavo A. R. Silva
2020-05-11 12:02   ` Kalle Valo
2020-05-11 12:46     ` Arnd Bergmann
2020-05-11 13:09       ` Kalle Valo
2020-05-11 13:47         ` Arnd Bergmann
2020-05-12  7:33 ` Kalle Valo

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \

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