linux-kernel - Re: [PATCH v1 1/1] x86/defconfigs: Explicitly unset CONFIG_64BIT in i386

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] [day] [month] [year] [list]

Message-ID: <aFki6aGz60hIWvH1@smile.fi.intel.com>
Date: Mon, 23 Jun 2025 12:48:25 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Díaz <daniel.diaz@...aro.org>
Subject: Re: [PATCH v1 1/1] x86/defconfigs: Explicitly unset CONFIG_64BIT in
 i386_defconfig

On Mon, Jun 23, 2025 at 12:46:45PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 23, 2025 at 11:31:56AM +0200, Borislav Petkov wrote:
> > On Mon, Jun 23, 2025 at 12:21:03PM +0300, Andy Shevchenko wrote:
> > > Ah, this is just a cherry-pick (with fixing conflicts, updated Fixes
> > > and removed the last paragraph) of 5y.o. 76366050eb1b ("x86/defconfigs:
> > > Explicitly unset CONFIG_64BIT in i386_defconfig"),
> > 
>> >  > What?

FWIW< the bug is repetitive (third time already?) that the i386_defconfig was
refreshed with ARCH=x86_64 or so and in the result the CONFIG_64BIT is set to
'y' for 32-bit code.

> > A 5yo patch cherrypicked from somewhere has as a Fixes tag a patch from 10
> > days ago?!?!
> 
> The base for my patch was the 5.y.o. patch.
> 
> > > it should be standalone patch. I borrowed the commit message.  So, whatever
> > > you prefer: I can send it again as the original one, one of x86 maintainers
> > > can do themselves the cherry-picking / conflict resolution, or I can resend
> > > it as mine.
> > 
> > You should do a proper patch as it is done and not do a mish-mash of old and
> > new things, clarify with Daniel who's going to be the author and you should
> > write a commit message which explains the situation properly, not borrow one.
> 
> It is describes situation properly. Just a test was different in this case.
> Okay, let me try again in v2.

-- 
With Best Regards,
Andy Shevchenko