linux-kernel - Re: [PATCH 4/8] tools: Remove s390 compat support

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: <20251113194505.7746Bc8-hca@linux.ibm.com>
Date: Thu, 13 Nov 2025 20:45:05 +0100
From: Heiko Carstens <hca@...ux.ibm.com>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Alexander Gordeev <agordeev@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Andreas Krebbel <krebbel@...ux.ibm.com>, Arnd Bergmann <arnd@...db.de>,
        Willy Tarreau <w@....eu>, Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org
Subject: Re: [PATCH 4/8] tools: Remove s390 compat support

On Thu, Nov 13, 2025 at 04:43:59PM +0100, Thomas Weißschuh wrote:
> On 2025-11-13 16:07:26+0100, Heiko Carstens wrote:
> > Remove s390 compat support from everything within tools, since s390 compat
> > support will be removed from the kernel.
> > 
> > While removing s390 compat code replace __s390__ ifdef guards with
> > __s390x__ everywhere. Even though this is not strictly required this
> > makes it easier to spot s390 compat code support leftovers.
> > 
> > Reviewed-by: Arnd Bergmann <arnd@...db.de>
> > Signed-off-by: Heiko Carstens <hca@...ux.ibm.com>
> > ---
> >  .../arch/s390/include/uapi/asm/bitsperlong.h  |  4 --
> 
> Wouldn't it make sense to emit an explicit error from the UAPI
> headers if a user tries to use them in 31-bit mode?

Except for some CIs there shouldn't be any users. I would expect that such
users, which use the kernel header files for compilation, want to run the
(broken) binary with the kernel which supplied the header files - which does
not work since compat support is missing in the kernel. So it fails when
trying to execute the binary.

Or in other words: I really would like to get rid of all traces of 31/32 bit
support without adding anything new.