[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj_b+FGTnevQSBAtCWuhCk=0oQ_THvthBW2hzqpOTLFmg@mail.gmail.com>
Date: Thu, 10 Aug 2023 17:37:46 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "Borislav Petkov (AMD)" <bp@...en8.de>, linux-kernel@...r.kernel.org,
linux-tip-commits@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>,
Daniel Kolesa <daniel@...aforge.org>, Naresh Kamboju <naresh.kamboju@...aro.org>,
Sven Volkinsfeld <thyrc@....net>, Nick Desaulniers <ndesaulniers@...gle.com>, x86@...nel.org,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, Martin KaFai Lau <martin.lau@...ux.dev>
Subject: Re: [tip: x86/bugs] x86/srso: Fix build breakage with the LLVM linker
On Thu, 10 Aug 2023 at 17:29, Jakub Kicinski <kuba@...nel.org> wrote:
>
> Are the commit IDs stable on x86/bugs?
I think normally yes.
> Would it be rude if we pulled that in?
If this is holding stuff up, you have a pretty good excuse. It
shouldn't be the normal workflow, but hey, it's not a normal problem.
As I mentioned elsewhere, I hate the embargoed stuff, and every single
time it happens I expect fallout from the fact that we couldn't use
the usual bots for build and boot testing.
All our processes are geared towards open development, and I think
that's exactly how they *should* be.
But then that means that they fail horribly for the embargoes.
Anyway, go ahead and just pull in the fixes if this holds up your
normal workflow.
And if we end up with duplicates due to rebases (or worse yet, merge
issues due to rebases with other changes), it is what it is. Can't
blame you.
Linus
Powered by blists - more mailing lists