linux-kernel - Re: [GIT PULL] x86/apic for v6.18-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wg65RDkvPd3rFZr32n8L_LQJAcWie1K-=azcLS6Y5JwkQ@mail.gmail.com>
Date: Mon, 6 Oct 2025 08:59:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...nel.org>, x86-ml <x86@...nel.org>, 
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/apic for v6.18-rc1

On Mon, 6 Oct 2025 at 05:29, Borislav Petkov <bp@...en8.de> wrote:
>
> Sorry for the confusion.

So the biggest issue really was just the explanations. Both the
explanation for why the merge happened in the first place, but then
also the resulting explanation in the pull request.

Due to the merge, I feel that the explanations in *my* merge ends up
being less than great. I think it would have been good to just have
separate explanations for the apic init thing and the SEV parts,
because they seem entirely independent.

But maybe they weren't as independent as I think they are, and there
was some deeper reason for the merge that just was never explained.

Basically, a conflict is never a reason for a merge. That would be
unphysical: conflicts happen _due_ to a merge, so a merge is the
reason for a conflict, not the other way around.

If the merge was done for some linux-next or testing purpose, then the
merging should have been done in a branch _for_ testing or linux-next
integration, and then there would be a reason  ("merge for testing /
linux-next").

And if the merge is because of some future conflict resolution, then
that should be stated too ("This conflict is so complicated that we
don't trust that Linus will get it right, so we're merging it for him.
Linus needs all the help he can get, and he's not always at his
sharpest").

But "merge due to a conflict" is simply never a reason in itself. It's
like saying "The sun came up because I woke up". That's not how the
world works.

            Linus