archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <>
To: "Nick Desaulniers" <>,
	"Martin Liška" <>
Cc: "Roman Kiryanov" <>,
	"Rafael J. Wysocki" <>,
	"Pavel Machek" <>,
	"Thomas Gleixner" <>,
	"Ingo Molnar" <>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<>,, "Greg KH" <>,
	"Alistair Delva" <>,
	"Haitao Shan" <>,
	lkml <>,
	"Sami Tolvanen" <>,
	clang-built-linux <>,
	"Martin Liška" <>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)
Date: Tue, 15 Sep 2020 22:20:34 +0200	[thread overview]
Message-ID: <20200915202034.GZ14436@zn.tnic> (raw)
In-Reply-To: <>

On Tue, Sep 15, 2020 at 12:51:47PM -0700, Nick Desaulniers wrote:
> I agree; I also would not have sent the patch though.

Maybe google folks should run stuff by you before sending it up... :-)

> Until LTO has landed upstream, this is definitely somewhat self
> inflicted. This was only debugged last week; even with a compiler fix
> in hand today, it still takes time to ship that compiler and qualify
> it; for other folks on tighter timelines, I can understand why the
> patch was sent,

... because they have the requirement that a patch which gets backported
to a kernel used at google needs to be upstream? Because I'm willing to
bet a lot of cash that no one runs bleeding egde 5.9-rcX in production
over there right now :-)

> and do genuinely appreciate the effort to participate more upstream
> which I'm trying to encourage more of throughout the company (we're
> in a lot of technical debt kernel-wise; and I'm not referring to
> Android...a story over beers perhaps, or ask Greg).

Beers? Always. But I can imagine the reasons: people working on projects
and then those projects getting done and no one cares about upstreaming
stuff after the fact or no one has time ... or policy ... but let's keep
that for beers. :-)

> It's just that this isn't really appropriate since it works around
> a bug in a non-upstream feature, and will go away once we fix the
> toolchain.


> It would be much nicer if we had the flexibility to disable stack
> protectors per function, rather than per translation unit.  I'm going
> to encourage you to encourage your favorite compile vendor ("write to
> your senator") to support the function attribute
> __attribute__((no_stack_protector)) so that one day,

I already forgot why gcc doesn't do that... Martin, do you know?

> we can use that to stop shipping crap like a9a3ed1eff360 ("x86: Fix
> early boot crash on gcc-10, third try"). Having had that, we could
> have used a nicer workaround until the toolchain was fixed (and one
> day revert a9a3ed1eff360, and d0a8d9378d16, and probably more hacks in
> the kernel).

Yap, agreed. I guess with those new compiler features it is always a
couple of releases - both kernel, i.e., the user of that feature, and
compiler, i.e., the provider of the feature, to both figure out what
the proper use cases are, to experiment a bit and then to adjust stuff,
change here and there and then cast in stone. Oh well.

> And the case that's causing the compiler bug in question is something
> all compiler vendors will need to consider in their implementations.

Are you talking to gcc folks about it already so that they DTRT too?

Btw, if it is any consolation, talking to compiler folks is like a charm
in comparison to talking to hardware vendors and trying to get them
to agree on something because they seem to think that the kernel is
software and sure, can be changed to do whatever. But that's another
story for the beers... :-)


  reply	other threads:[~2020-09-15 22:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 17:26 rkir
2020-09-15 17:46 ` Borislav Petkov
2020-09-15 17:57   ` Roman Kiryanov
2020-09-15 18:27     ` Borislav Petkov
2020-09-15 18:36       ` Roman Kiryanov
2020-09-15 18:52         ` Borislav Petkov
2020-09-15 18:55           ` Roman Kiryanov
2020-09-18 22:25         ` Pavel Machek
2020-09-21 23:28           ` Roman Kiryanov
2020-10-04  9:59             ` Pavel Machek
2020-09-15 18:00   ` Nick Desaulniers
2020-09-15 18:25     ` Borislav Petkov
2020-09-15 19:51       ` Nick Desaulniers
2020-09-15 20:20         ` Borislav Petkov [this message]
2020-09-15 21:49           ` Nick Desaulniers
2020-09-16  9:23             ` Borislav Petkov
2020-09-19 16:48             ` Pavel Machek
2020-09-16  8:17         ` peterz
2020-09-15 20:44     ` Arvind Sankar
2020-09-15 22:17 ` Pavel Machek
2020-09-15 22:21   ` Nick Desaulniers
2020-09-18 22:20     ` Pavel Machek
2020-09-15 23:13   ` Roman Kiryanov

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=20200915202034.GZ14436@zn.tnic \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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