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: "Martin Liška" <mliska@suse.cz>,
	"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>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)
Date: Tue, 15 Sep 2020 14:49:40 -0700	[thread overview]
Message-ID: <CAKwvOdmmXEu40m9bVL9zY5XyBRs2f15cs3FZQLCCh4u3i07pDA@mail.gmail.com> (raw)
In-Reply-To: <20200915202034.GZ14436@zn.tnic>

On Tue, Sep 15, 2020 at 1:20 PM Borislav Petkov <bp@alien8.de> wrote:
>
> 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... :-)

Ha!

1. they don't pay me enough for that.
2. even if they did, I wouldn't want that responsibility
3. I'm probably least qualified for that.  Google has many strong
upstream contributors with much longer contribution history than
myself.  Maybe toolchain specific stuff though...
4. you generally don't want people like that in any organization.
More gatekeepers winds up being a synchronization/contention point.
Remember, the goal is to train others to be self sufficient, so you
can drink margaritas on the roof.  That suggestion goes against the
ultimate goal.
5. You'd think a multi-billion-dollar per quarter company could hire a
few more people to help; instead stock buybacks are more attractive I
guess?  Maybe better ROI?  I suspect one too many managers
internalized the Mythical Man Month's point about "adding more people
to a late software project just makes it later" to mean "starve your
projects for resources" and run a ghost-ship (ie. big boat, with
little to no deck hands to ensure the boat doesn't "Costa Concordia"
(noun-as-a-verb...oh well)).  To be fair, hiring has been impacted by
COVID; my point is more so being stretched incredibly thin.  There's
been what, 3 Clang related kernel bugs you and I have been CC'ed on
today.  Hard to fix compiler bugs AND triage from the fire hose.  I
should probably just put down LKML for today and start fixing the
[haunted][damned] compiler.

>
> > 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?

That's a rule for stable, yes.  But also because we have folks that
don't seem to understand (moreso maybe haven't considered) that
"forking is not free" when upstream moves faster than you and you'd
also like to rebase someday; as such acquiring technical debt at a
rate that's impossible to pay off.

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

I guess you're paying for beers then.  "Android Common Kernels" run
mainline.  (They're a bit esoteric in terms of "production" but
cuttlefish virtual devices are running Android on mainline).

> > 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?

Martin has patches for that, he has CC'ed me when sending them
upstream for review.  Review was stalled, so I provided some feedback.
I'll review a GCC patch (once it's updated with my previous feedback)
if I have to; I'm not against it. w/e so long as we have a timeline
for a kernel fix.

> > 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?

I CC'ed Martin on the LLVM bug, since this is a case I'm looking for
his input on, or at least for him to be aware of the test case.

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

I look forward to it.
-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2020-09-15 21:51 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
2020-09-15 21:49           ` Nick Desaulniers [this message]
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=CAKwvOdmmXEu40m9bVL9zY5XyBRs2f15cs3FZQLCCh4u3i07pDA@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).