LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Sergei Trofimovich <slyfox@gentoo.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	x86@kernel.org
Subject: Re: [PATCH] x86: fix early boot crash on gcc-10
Date: Tue, 17 Mar 2020 12:46:05 +0100
Message-ID: <20200317114605.GG2156@tucnak> (raw)
In-Reply-To: <20200316221251.7b4f5801@sf>

On Mon, Mar 16, 2020 at 10:12:51PM +0000, Sergei Trofimovich wrote:
> In case you are still interested in preprocessed files and results I've collected
> all the bits in a single tarball:
>     https://dev.gentoo.org/~slyfox/bugs/linux-gcc-10-boot-2020-03-14.tar.gz
> Same available in separate files in:
>     https://dev.gentoo.org/~slyfox/bugs/linux-gcc-10-boot-2020-03-14/

Thanks, that is helpful.
So, a few comments.

One thing I've noticed in the command line is that
--param=allow-store-data-races=0
got dropped.  That is fine, the parameter is gone, but it has been replaced
in https://gcc.gnu.org/PR92046 by the
-fno-allow-store-data-races
option.  Like the param which defaulted to 0 and has been enabled only with
-Ofast this option is also -fno-allow-store-data-races by default unless
-Ofast, but if kernel wanted to be explicit or make sure not to introduce
them even with -Ofast, I'd say it should:
 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS   += $(call cc-option,--param=allow-store-data-races=0)
+KBUILD_CFLAGS   += $(call cc-option,-fno-allow-store-data-races)
in the toplevel Makefile.

The actual change that causes cpu_startup_entry to be tail called in GCC 10
was my https://gcc.gnu.org/PR59813 https://gcc.gnu.org/PR89060
https://gcc.gnu.org/r10-230-gab87ac8d53f3d903bfc9eeb0f0b5e7eed1f38cbc
optimization.  Previously, GCC punted just because it saw some earlier call
which passed address of some automatic variable to some other function and
escaped it that way (and could be possibly used during the function
considered for tail call, thus making the tail call not possible as with
tail call the frame is gone then).  Now, GCC tries to use information about
scopes to determine that eventhough some automatic variables can escape that
way, if they aren't in the scope anymore during the last call, they
shouldn't be problematic.  There are two variables that prevented the tail
call optimization in the past it seems, int cpuid; in smp_callin function
which is inlined, then its address escapes:
__dynamic_pr_debug(&__UNIQUE_ID_ddebug114, "smpboot" ": " "Stack at about %p\n", &cpuid);
and then cpuid goes out of scope.
Similarly, the u64 canary; variable in boot_init_stack_canary which is also
inlined.  The address escapes in
get_random_bytes(&canary, sizeof(canary));
and later on is used and eventually goes out of scope.
Finally, there is the cpu_startup_entry call at the end of function.

Regarding the reason why GCC doesn't tailcall noreturn functions, that is a
deliberate decision, often that results in shorter code (there is no need to
restore stack etc. before the call and because it is noreturn, anything
after the call can be thrown away as unreachable) and more importantly,
results in more useful backtraces when something calls abort etc.

Hope this helps.

	Jakub


  reply index

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-14 16:44 Sergei Trofimovich
2020-03-16 13:04 ` Peter Zijlstra
2020-03-16 13:26   ` Jakub Jelinek
2020-03-16 13:42     ` Peter Zijlstra
2020-03-16 17:54       ` Borislav Petkov
2020-03-16 18:03         ` Jakub Jelinek
2020-03-17 14:36           ` Borislav Petkov
2020-03-17 14:39             ` Jakub Jelinek
2020-03-17 14:49               ` Borislav Petkov
2020-03-17 16:35                 ` David Laight
2020-03-25 13:31                 ` Borislav Petkov
2020-03-26 21:54                   ` Sergei Trofimovich
2020-03-26 22:35                     ` Borislav Petkov
2020-03-28  8:48                       ` [PATCH v2] " Sergei Trofimovich
2020-04-13 14:15                         ` [tip: x86/urgent] x86: Fix " tip-bot2 for Sergei Trofimovich
2020-04-13 16:35                         ` [PATCH v2] x86: fix " Borislav Petkov
2020-04-14 13:50                           ` Michael Matz
2020-04-15  7:48                             ` Borislav Petkov
2020-04-15 14:53                               ` Michael Matz
2020-04-15 22:19                                 ` Sergei Trofimovich
2020-04-17  7:57                                   ` Borislav Petkov
2020-04-17  8:07                                     ` Jakub Jelinek
2020-04-17  8:42                                       ` Borislav Petkov
2020-04-17  8:58                                         ` Jakub Jelinek
2020-04-17  9:09                                           ` Borislav Petkov
2020-04-17 18:15                                             ` Nick Desaulniers
2020-04-17 18:22                                               ` Nick Desaulniers
2020-04-17 19:06                                                 ` Jakub Jelinek
2020-04-17 19:49                                                   ` Nick Desaulniers
2020-04-17 19:53                                                     ` Nick Desaulniers
2020-04-20 14:04                                                     ` Michael Matz
2020-04-22 10:23                                                       ` Borislav Petkov
2020-04-22 11:40                                                         ` Peter Zijlstra
2020-04-22 13:49                                                           ` Borislav Petkov
2020-04-22 13:55                                                             ` Jakub Jelinek
2020-04-22 14:16                                                               ` Martin Liška
2020-04-22 15:06                                                                 ` Michael Matz
2020-04-22 16:53                                                                 ` Borislav Petkov
2020-04-22 17:02                                                                   ` Jakub Jelinek
2020-04-22 18:47                                                                   ` Nick Desaulniers
2020-04-22 18:55                                                         ` Nick Desaulniers
2020-04-22 19:21                                                           ` Borislav Petkov
2020-04-22 21:05                                                             ` Nick Desaulniers
2020-04-22 21:26                                                               ` Borislav Petkov
2020-04-22 22:57                                                                 ` Nick Desaulniers
2020-04-23 12:53                                                                   ` Borislav Petkov
2020-04-23 16:12                                                                     ` [PATCH] x86: Fix early boot crash on gcc-10, next try Borislav Petkov
2020-04-23 17:30                                                                       ` Borislav Petkov
2020-04-23 18:02                                                                         ` Nick Desaulniers
2020-04-23 18:27                                                                           ` Borislav Petkov
2020-04-27 11:37                                                                         ` [tip: x86/build] x86/build: Check whether the compiler is sane tip-bot2 for Borislav Petkov
2020-04-23 19:40                                                                       ` [PATCH] x86: Fix early boot crash on gcc-10, next try Kees Cook
2020-04-25  1:46                                                                       ` Arvind Sankar
2020-04-25  8:57                                                                         ` Borislav Petkov
2020-04-25 11:09                                                                           ` Jürgen Groß
2020-04-25 15:04                                                                           ` Arvind Sankar
2020-04-25 17:31                                                                             ` Borislav Petkov
2020-04-25 17:52                                                                               ` Borislav Petkov
2020-04-27 17:07                                                                                 ` David Laight
2020-04-25 18:37                                                                               ` Segher Boessenkool
2020-04-25 18:53                                                                                 ` Borislav Petkov
2020-04-25 19:15                                                                                   ` Segher Boessenkool
2020-04-25 22:17                                                                                     ` Borislav Petkov
2020-04-25 22:25                                                                                     ` Arvind Sankar
2020-04-17 10:38                                           ` [PATCH v2] x86: fix early boot crash on gcc-10 Peter Zijlstra
2020-04-18 13:12                                             ` David Laight
2020-04-17 10:41                                     ` Peter Zijlstra
2020-03-16 18:20         ` [PATCH] " Arvind Sankar
2020-03-16 18:54           ` Arvind Sankar
2020-03-16 19:53             ` Arvind Sankar
2020-03-16 20:08               ` Jakub Jelinek
2020-03-16 20:40                 ` Arvind Sankar
2020-03-16 22:12     ` Sergei Trofimovich
2020-03-17 11:46       ` Jakub Jelinek [this message]
2020-03-17 18:10         ` Sergei Trofimovich
2020-03-16 18:22 ` Arvind Sankar
2020-03-26 23:16 ` [PATCH v2] " Sergei Trofimovich
2020-04-27 11:37 ` [tip: x86/build] x86: Fix early boot crash on gcc-10, next try tip-bot2 for Borislav Petkov
2020-05-15 11:20 ` [tip: x86/urgent] x86: Fix early boot crash on gcc-10, third try tip-bot2 for Borislav Petkov

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=20200317114605.GG2156@tucnak \
    --to=jakub@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=slyfox@gentoo.org \
    --cc=tglx@linutronix.de \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git