linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Roman Kiryanov" <rkir@google.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	linux-pm@vger.kernel.org, "Greg KH" <gregkh@linuxfoundation.org>,
	"Alistair Delva" <adelva@google.com>,
	"Haitao Shan" <hshan@google.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"Sami Tolvanen" <samitolvanen@google.com>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	"Martin Liška" <mliska@suse.cz>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)
Date: Tue, 15 Sep 2020 12:51:47 -0700	[thread overview]
Message-ID: <CAKwvOdkKk1KuAFDoWNLnMUi3_JnV7atDFnvS7CdkgNXnNg0p1g@mail.gmail.com> (raw)
In-Reply-To: <20200915182530.GV14436@zn.tnic>

On Tue, Sep 15, 2020 at 11:25 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Sep 15, 2020 at 11:00:30AM -0700, Nick Desaulniers wrote:
> > This is exactly the same code from __restore_processor_state.
>
> No, this patch is adding
>
> #ifdef __clang__
>
> and I don't like the sprinkling around of those compiler-specific
> workarounds which we have to carry forward forever or at least until
> that compiler version is deprecated. We already carry fixes for broken
> hardware, broken BIOSes, broken peripherals,... can you follow the
> progression? :)

I agree; I also would not have sent the patch though.  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, 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).  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.

>
> So your argument about testing unreleased compilers in the other thread
> makes a lot of sense so that stuff like that can be fixed in time, and
> in the compiler, where it belongs (that is, *if* it belongs there).

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, 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).  And the case that's causing the compiler bug in question is
something all compiler vendors will need to consider in their
implementations.
-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2020-09-15 19:53 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 [this message]
2020-09-15 20:20         ` Borislav Petkov
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:
  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=CAKwvOdkKk1KuAFDoWNLnMUi3_JnV7atDFnvS7CdkgNXnNg0p1g@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=adelva@google.com \
    --cc=bp@alien8.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hshan@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mliska@suse.cz \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=rkir@google.com \
    --cc=samitolvanen@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)' \
    /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

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