linux-kernel - Re: [PATCH 6/8] CMDLINE: x86: convert to generic builtin command line

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: <1759444692.24579.8.camel@chimera>
Date: Thu, 02 Oct 2025 15:38:12 -0700
From: Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Daniel Walker (danielwa)" <danielwa@...co.com>, Will Deacon
 <will@...nel.org>, Christophe Leroy <christophe.leroy@...roup.eu>, Rob
 Herring <robh@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
 Pratyush Brahma <quic_pbrahma@...cinc.com>, Tomas Mudrunka
 <tomas.mudrunka@...il.com>, Sean Anderson <sean.anderson@...o.com>,
 "x86@...nel.org" <x86@...nel.org>, "linux-mips@...r.kernel.org"
 <linux-mips@...r.kernel.org>, "linuxppc-dev@...ts.ozlabs.org"
 <linuxppc-dev@...ts.ozlabs.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo
 Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
 <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, 
 "xe-linux-external(mailer list)" <xe-linux-external@...co.com>, Ruslan
 Ruslichenko <rruslich@...co.com>,  Ruslan Bilovol
 <ruslan.bilovol@...il.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/8] CMDLINE: x86: convert to generic builtin command
 line

On Thu, 2025-10-02 at 14:55 -0700, Dave Hansen wrote:
> That's not a bad idea. Or, even if you can pick two amenable
> architectures to start with it will make it really obvious that this is
> useful. Two architectures means a *lot*, IMNHO. Two is a billion times
> better than one.

I think it's a bad idea, if I understand it correctly. The patchset
conceptually patches a mechanism of the kernel as a whole, but one which
just so happens to need to be implemented separately for each arch.
Breaking it down like you suggest creates an embarrassingly high
likelihood of different architectures' implementations of it going out
of sync, a previous situation that this patchset was partly intended to
address. I say keep it atomic. If it breaks on an arch or two but not
others and nobody notices right away, that would be better addressed
with a new patch when someone eventually does notice. Just my 2¢…