From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B413C02192 for ; Mon, 3 Feb 2025 11:58:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30840280002; Mon, 3 Feb 2025 06:58:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B8C9280001; Mon, 3 Feb 2025 06:58:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13393280002; Mon, 3 Feb 2025 06:58:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E6A66280001 for ; Mon, 3 Feb 2025 06:58:03 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CCCBAAD973 for ; Mon, 3 Feb 2025 11:55:58 +0000 (UTC) X-FDA: 83078479638.02.2E5BEBB Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by imf10.hostedemail.com (Postfix) with ESMTP id 665CDC000D for ; Mon, 3 Feb 2025 11:55:56 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=fu-berlin.de header.s=fub01 header.b=IGUFUiMt; spf=pass (imf10.hostedemail.com: domain of glaubitz@zedat.fu-berlin.de designates 130.133.4.66 as permitted sender) smtp.mailfrom=glaubitz@zedat.fu-berlin.de; dmarc=pass (policy=none) header.from=fu-berlin.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738583757; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WuSovR9QdAIaryYdW+A1g1o31MDAJLE+4vMtcjJlDmY=; b=pG2I8cCRJhoeD2I1zNXAd7x9BwAKuag1tfI22X/7sow6nZ/JDyj43guN+7z1TvyvVNOndz es/V3QcBafoJP4aePAD3hkm9E2r4T6mFzA0snr2jIVTmWGZHWm9aXJYz/zevpLfDmCvMQm Jijru1iQ3qLB2QgfC5ybaFTrFyRHKh4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=fu-berlin.de header.s=fub01 header.b=IGUFUiMt; spf=pass (imf10.hostedemail.com: domain of glaubitz@zedat.fu-berlin.de designates 130.133.4.66 as permitted sender) smtp.mailfrom=glaubitz@zedat.fu-berlin.de; dmarc=pass (policy=none) header.from=fu-berlin.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738583757; a=rsa-sha256; cv=none; b=rlZqJOtO6mLp0+VKM3+gVoUrPhZIbaRrsIq7aEooFwKXnUvJiuHfWE/6wOPGn841cOkH4n wrqc1O4FmRHiIJDVKooCae5MaQ3Z17bt9U7wXx0Eu73/3cuFL/39i7lBks2fahtfTHKr0r mvGbAOWLWZwts+Ol9wuuQqKnzmaLR38= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fu-berlin.de; s=fub01; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WuSovR9QdAIaryYdW+A1g1o31MDAJLE+4vMtcjJlDmY=; t=1738583756; x=1739188556; b=IGUFUiMtOmpa2fSMWFOY1ymdpK28rvJDqGzp2jWXSyYg/dB5/8iwtVYKYk515LDxIKxVUfdzfHl UX80XP9SAZJPiOrFcmdK0/RVmGB5ePXKn0ytwugsI7VX2EgQYeQhaX2ik3C5oX7e1xmQxEZ0pbbhl 7i5GWeakuj0KsyXpHoz/Ragv14j3jbdP88Mg6P5xhQWzDYhpWD9dR5T1dD7lmv/NA/P8djXuEZA+Q dFR6YwXhzi/X1ta11gi2LW3cpToAwTtw/Ts9sMISnNzSDCVWAEo06iUBy84SnZv1g8CSJnlRdPfNb QSNGcBr2h5Dsvm7zhUfxxVWjnmURpjYL5jtw==; Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.98) with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1tev3M-00000003S4r-39wC; Mon, 03 Feb 2025 12:55:48 +0100 Received: from p5dc55198.dip0.t-ipconnect.de ([93.197.81.152] helo=[192.168.178.61]) by inpost2.zedat.fu-berlin.de (Exim 4.98) with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1tev3M-00000003WUE-1xuf; Mon, 03 Feb 2025 12:55:48 +0100 Message-ID: <950a85c8651b193f95fa839fceaec68d40356555.camel@physik.fu-berlin.de> Subject: Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support From: John Paul Adrian Glaubitz To: "Eric W. Biederman" Cc: "Maciej W. Rozycki" , Arnd Bergmann , Richard Henderson , Matt Turner , Kees Cook , "Paul E. McKenney" , linux-alpha@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michael Cree , Sam James , Geert Uytterhoeven , Michael Karcher , Chris Hofstaedtler , util-linux@vger.kernel.org, linux-mips@vger.kernel.org, loongarch@lists.linux.dev Date: Mon, 03 Feb 2025 12:55:47 +0100 In-Reply-To: <87y0zfs26i.fsf_-_@email.froward.int.ebiederm.org> References: <20250103140148.370368-1-glaubitz@physik.fu-berlin.de> <24f03227-1b55-4e50-b6e9-7ac74fda2602@app.fastmail.com> <678ee681-12c3-4e79-a04b-495daf343846@app.fastmail.com> <82d33a2d-dffe-4268-a175-4536b3f9c07f@app.fastmail.com> <87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org> <2758fa70d237ff972b0c8d7114777dc4a20c8f3b.camel@physik.fu-berlin.de> <78f3ae1f68842a9d1af62caaac3929834ce6ecfa.camel@physik.fu-berlin.de> <87y0zfs26i.fsf_-_@email.froward.int.ebiederm.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 MIME-Version: 1.0 X-Original-Sender: glaubitz@physik.fu-berlin.de X-Originating-IP: 93.197.81.152 X-ZEDAT-Hint: PO X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 665CDC000D X-Stat-Signature: ibqsejd9peczpaa4eye1kzdnzd1rqg8f X-HE-Tag: 1738583756-195322 X-HE-Meta: U2FsdGVkX1+wS11HbVjG33YhuCcxtRnyvWjz0OnkOo4VqnnNIQ9gccjzjXdR3EHedeRbuSsaumxEAPmhhiPkUA6AmqZRpU0o/OBbtJhL5OCFQ4FgcXdLAw6fy57F1xHmW3XMl+IX/fs0v4yFStjMgua7ri6CRSxvoSCBoy8ugWeJfSS6odRM274Me3z0ckAFjnldMGlujNhLQR4plvMemem8BqYHrc1X+kBmELJn7mqrOUYTH3oBHqoG4equGfEkCqYIUkraNJ3+ust4Es4MnPNDJzZXN+oOPEMD+gUJZN/VxLiJiABRP9szQrqo0h8JtqkqQiQD0KGi+WuAP3qk3Sz7+Z+Yg+pLDuY9eL9qfpqSPw8EHak/jNID2iyoB7l1XjQV0mwzRclA28wEWuMTdHQvKkS27hPYgMZSPI8V7px5iRzKDempbqy+wWdE7s57sNG08PWNNC6pa0dR47V9PjVZf9H0t5xyFSgz0LBDlckbRkDnaWKoT4ou48yMHqHYabS1QCSuqd/ED5n8Cr5LexzBmxE2/TM9O31a752aNs6/3NnzSFHcKNF5iqrodrG6HYUxU0RjU6qW+t1ppov5aaTJRAIIhy76ANTiuXjAmBbghqqXKBGMoEldKHlM8uh1iDSXeZq4i6CzLkOo/ERJPJrtJD9391X+f3jf/bDZyqMVpdwiaNYhMt+KOfcAbdXWiqodxBkHZvZpEjN3TnuszPbrHei892YM3inx8JEQvn4XcSte5xGACAhH8D9M9xR7Rff8/3ALOr17LwEFe3VfzJdOxLlLca8kBFNzx77h2S/Kjmc7hC4iN9+MMm8vRlrnAe1YOV4HqnXgmN6+va9kewKOcEI8wORck3xNvueDn0grFppG48YnHva4VLZH2ZFG7y9EBcbRCARmd4fXPeLrDbHbhmc02G65Aue7FOdYsWfRaUjdpz+EAmvszXMVymc4WKLzoT75FUa/vjfCIWf C8NcokhS TsiBK82XZW+y8rMaKeTgDYCXFHRb57AUx5szrOKE0einNJtBO5iBvuQR8apLUArNFvrc2ulamV4YVXdv1hry7MWVhdUnea6KYi4Bzla+C4P8inCYCy2kHJL7a1WlrO8UyqI4XiAEPlVEzsHkJhP1kxk5KBgPCw6AAlV3FKrxh9ijH5ULxlnczubOKMFJJ0Fx9VA8nVMMcNB5YQS8EiEaqOosRbS/Y5sOfJ1OpbJxFwneAT4alQAjB2X8cSuP3lro3KgVGPs4E3sauVhuWjtKMib6AAMAqfgDDxojA+/JdqT2c71Zbsz2bgn4iCYmjDPU9bY4nCTcNCbVhExjbblBSZ3YlHsGSjACCzSZ0d5Mc6tuYst9lQ1eLMm1eYRwlbQ1AKKUFVKoSBpYc8iDSOOHcQyGwh+y1gm9XcEtIHOIrJiO4Nk5hT4/EJugQVXX7v246MEX8X3ZWm2nm/+ir73p4mJicoA7zreDIoO346cKOLXRK5iZWhPuqYWJwKXXpNuhKhgBUM5Vtgt43c1K5VAKiojpOUKEl0qp+h5bAUopY5TrXaX3VSFcA3BSyoUyI2iMw9XECIC6GP5RmfP3WgdjvPsEq4dE/CpvQURrQKEOP32GrsTgckHVzHj/5Hv0nWQav45j0Xc50BAL+KLi407aELNd9oYiMbKK2OrP0oSjBu4CbBJA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, On Sun, 2025-01-12 at 23:39 -0600, Eric W. Biederman wrote: > Richard Henderson writes[1]: >=20 > > There was a Spec benchmark (I forget which) which was memory bound and = ran > > twice as fast with 32-bit pointers. > >=20 > > I copied the idea from DEC to the ELF abi, but never did all the other = work > > to allow the toolchain to take advantage. > >=20 > > Amusingly, a later Spec changed the benchmark data sets to not fit into= a > > 32-bit address space, specifically because of this. > >=20 > > I expect one could delete the ELF bit and personality and no one would > > notice. Not even the 10 remaining Alpha users. >=20 > In [2] it was pointed out that parts of setarch weren't working > properly on alpha because it has it's own SET_PERSONALITY > implementation. In the discussion that followed Richard Henderson > pointed out that the 32bit pointer support for alpha was never > completed. >=20 > Fix this by removing alpha's 32bit pointer support. >=20 > As a bit of paranoia refuse to execute any alpha binaries that have > the EF_ALPHA_32BIT flag set. Just in case someone somewhere has > binaries that try to use alpha's 32bit pointer support. >=20 > [1] https://lkml.kernel.org/r/CAFXwXrkgu=3D4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq= 4ttm52pJOQ@mail.gmail.com > [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-= berlin.de > v1: https://lkml.kernel.org/r/87jzb2tdb7.fsf_-_@email.froward.int.ebieder= m.org > Reviewed-by: Richard Henderson > Reviewed-by: Arnd Bergmann > Reviewed-by: John Paul Adrian Glaubitz > Tested-by: John Paul Adrian Glaubitz > Signed-off-by: "Eric W. Biederman" > --- >=20 > Kees can you pick this one up? >=20 > arch/alpha/include/asm/elf.h | 6 +----- > arch/alpha/include/asm/pgtable.h | 2 +- > arch/alpha/include/asm/processor.h | 8 ++------ > arch/alpha/kernel/osf_sys.c | 11 ++--------- > 4 files changed, 6 insertions(+), 21 deletions(-) >=20 > diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h > index 4d7c46f50382..50c82187e60e 100644 > --- a/arch/alpha/include/asm/elf.h > +++ b/arch/alpha/include/asm/elf.h > @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG]; > /* > * This is used to ensure we don't load something for the wrong architec= ture. > */ > -#define elf_check_arch(x) ((x)->e_machine =3D=3D EM_ALPHA) > +#define elf_check_arch(x) (((x)->e_machine =3D=3D EM_ALPHA) && !((x)->e_= flags & EF_ALPHA_32BIT)) > =20 > /* > * These are used to set parameters in the core dumps. > @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct ta= sk_struct *task); > : amask (AMASK_CIX) ? "ev6" : "ev67"); \ > }) > =20 > -#define SET_PERSONALITY(EX) \ > - set_personality(((EX).e_flags & EF_ALPHA_32BIT) \ > - ? PER_LINUX_32BIT : PER_LINUX) > - > extern int alpha_l1i_cacheshape; > extern int alpha_l1d_cacheshape; > extern int alpha_l2_cacheshape; > diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pg= table.h > index 635f0a5f5bbd..02e8817a8921 100644 > --- a/arch/alpha/include/asm/pgtable.h > +++ b/arch/alpha/include/asm/pgtable.h > @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte= ) > =20 > extern void paging_init(void); > =20 > -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT. */ > +/* We have our own get_unmapped_area */ > #define HAVE_ARCH_UNMAPPED_AREA > =20 > #endif /* _ALPHA_PGTABLE_H */ > diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/= processor.h > index 55bb1c09fd39..5dce5518a211 100644 > --- a/arch/alpha/include/asm/processor.h > +++ b/arch/alpha/include/asm/processor.h > @@ -8,23 +8,19 @@ > #ifndef __ASM_ALPHA_PROCESSOR_H > #define __ASM_ALPHA_PROCESSOR_H > =20 > -#include /* for ADDR_LIMIT_32BIT */ > - > /* > * We have a 42-bit user address space: 4TB user VM... > */ > #define TASK_SIZE (0x40000000000UL) > =20 > -#define STACK_TOP \ > - (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000U= L) > +#define STACK_TOP (0x00120000000UL) > =20 > #define STACK_TOP_MAX 0x00120000000UL > =20 > /* This decides where the kernel will search for a free chunk of vm > * space during mmap's. > */ > -#define TASK_UNMAPPED_BASE \ > - ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / = 2) > +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2) > =20 > /* This is dead. Everything has been moved to thread_info. */ > struct thread_struct { }; > diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c > index 86185021f75a..a08e8edef1a4 100644 > --- a/arch/alpha/kernel/osf_sys.c > +++ b/arch/alpha/kernel/osf_sys.c > @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user= *, txc_p) > return ret; > } > =20 > -/* Get an address range which is currently unmapped. Similar to the > - generic version except that we know how to honor ADDR_LIMIT_32BIT. *= / > +/* Get an address range which is currently unmapped. */ > =20 > static unsigned long > arch_get_unmapped_area_1(unsigned long addr, unsigned long len, > @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned= long addr, > unsigned long len, unsigned long pgoff, > unsigned long flags, vm_flags_t vm_flags) > { > - unsigned long limit; > - > - /* "32 bit" actually means 31 bit, since pointers sign extend. */ > - if (current->personality & ADDR_LIMIT_32BIT) > - limit =3D 0x80000000; > - else > - limit =3D TASK_SIZE; > + unsigned long limit =3D TASK_SIZE; > =20 > if (len > limit) > return -ENOMEM; Tested-by: John Paul Adrian Glaubitz Can someone pick up this patch for v6.14? Adrian --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913