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 D73D8E77197 for ; Thu, 9 Jan 2025 20:10:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 162066B00B2; Thu, 9 Jan 2025 15:10:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 112B16B00B3; Thu, 9 Jan 2025 15:10:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 000416B00B4; Thu, 9 Jan 2025 15:10:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D46366B00B2 for ; Thu, 9 Jan 2025 15:10:44 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 86C641204B5 for ; Thu, 9 Jan 2025 20:10:44 +0000 (UTC) X-FDA: 82989006408.27.C01AAD3 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 64AE920009 for ; Thu, 9 Jan 2025 20:10:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=none (imf13.hostedemail.com: domain of macro@orcam.me.uk has no SPF policy when checking 78.133.224.34) smtp.mailfrom=macro@orcam.me.uk; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736453442; 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: in-reply-to:in-reply-to:references:references; bh=xKvgjncTI+Kmjyh3oJ17/zNS5rau4Fuyzis8fJen3XE=; b=Bv3qElmm6mO/B+4iWEJyjAtvqMaQjxfQQkp/IxQb79+kxFZhIr0tsN3iOStFeLNKpLl/cK 4CYbHyQZM/k/UYdScJeElZFLADiZCuYav2DTxYykIzYf6L3XYTDDlEn7D76NOXisDN4Jjv 9Ewuzx9q3GfRYC2Zvp042SRUVFfKCxE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=none (imf13.hostedemail.com: domain of macro@orcam.me.uk has no SPF policy when checking 78.133.224.34) smtp.mailfrom=macro@orcam.me.uk; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736453442; a=rsa-sha256; cv=none; b=Yr/leKGNcJ0B3fAJj1hNheyTCISVMsgjz/xHTY/fj7o6U47SFMo8sU2Jf2BPmeq23AwGxM Q1uH3l8TznaMN2B6nhXQ6i193RZP4UfqgXmsH8o7NkSfZuM0uV4u/XR8i/Omml8x90htvT ETuDUQVEu+3GQJoxiB460UKrQD8aneM= Received: by angie.orcam.me.uk (Postfix, from userid 500) id 834E392009D; Thu, 9 Jan 2025 21:10:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 7D11292009C; Thu, 9 Jan 2025 20:10:39 +0000 (GMT) Date: Thu, 9 Jan 2025 20:10:39 +0000 (GMT) From: "Maciej W. Rozycki" To: "Eric W. Biederman" cc: John Paul Adrian Glaubitz , 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 Subject: Re: [PATCH] alpha: Fix personality flag propagation across an exec In-Reply-To: <87ed1cufj1.fsf@email.froward.int.ebiederm.org> Message-ID: 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> <87ed1cufj1.fsf@email.froward.int.ebiederm.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam05 X-Stat-Signature: 3azn8zq3ms41hmyhdtugp6z9z1385ogj X-Rspamd-Queue-Id: 64AE920009 X-Rspam-User: X-HE-Tag: 1736453442-889702 X-HE-Meta: U2FsdGVkX189pG0H6JxfrCyGd0e2Pd9PvqaOEsQFHAlUkH35COtk6wz2BpJ9MDgqfKGaiUVtz0Fl6rY7lcPNmLsoi3e8etcJOjAIw083ktr7FUMtlfDU4IQ/h/dZzcElVlKJlX85RPvC9C43q9+yg/f1CB3jeLibfZjibJI45KY4RldjKlTkr9xOXTyCXKisB1fqUrjE6L4BQCtgjriPIp7ca1r/cuCBzZd28gJXFmkrmZyHAhaVpK/ip6fSWnJ/qPMoqJVK+ByVGX5NvNRA3+xYFqs4SYNoYMiP9TztlZ8RFpGgl/TqUiON4a4qKatJuKlJxiIfp1qkxcTDoDKYGS9aQrNtUGTX0b8JyggWm23TXcxSsT9+hnooDQZC9Xg5MeZGQPAa00krQzbkaGHP2K3JdzsbABqmjpw3jpKuvqDFxGlNQCyfjI941Q9zbV31+ooXVnnra7nriJW7IeP4TJjW5TzAzAq8vQegAuitpJoJP470MeUFDklvlnOcpli16CZyLU17jBISQlLMJmB9Z8ceL/aZ5uIN6To/kQDJLb3XuJ/bP7kMPOn+z6ZCaP30g7Hf1GbRJbgX1t4pwlQYPQrbr5uCGrf575I8pLgPqOw3gYDyAORrHGfsvdqWEfxfSFNtATkdtuI1zbNVQOxmSJYXIWbiNRgzkr1NmxRKd/Nrw7Banibmsp+LiSza4b6yP1WhXJveqKu27ccfJrs6gBvALxvxhzpun0UbganQ7ts3O1wmAJ9r3/dVz05K9En8SVxtpTw1exclkRAlP2PPnS07Q+bhRFhU9d8bnfQ9DacdYRng8k31pJt2a23p9kzgyOgXsnVm19OZGonSTST5jA1KNj1eEQoYS/2sW8ieLpYpnliVGGyQ4wjpImyGOGD8/BrdOEsbpiPl2PnE5TZ62FTcP96/zoufSGLLUVJTGDhgHvZVGehcwsWsPPBJUJh699M51ueSqcCwDiSLVB3 DjLQBKds 2JCU4l4zq0saq4BhVGYVL3Ev2P3hjumQL2PR3JeJo3/jpZBolSUII/DH2XcSoi6dBYY4A 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: On Thu, 9 Jan 2025, Eric W. Biederman wrote: > > So, this would be the 100% correct for alpha then which would not loose > > any functionality even for 32-bit binaries? > > I don't think it is correct to think about 32-bit binaries on alpha. > > Alpha never had a 32bit instruction set. But at some point it looks > like binaries that could not handle more than 31 bits of address > space got ported and someone implemented a work-around. I guess this > is the --taso option that Arnd mentioned. This also saves some code space in non-PIE and plain static executables as it takes fewer machine instructions to load a 64-bit address that is known beforehand to be a sign-extended 32-bit value. This is similar to the MIPS n32 ABI, which also implies a 32-bit address space while still using 64-bit registers for everything, starting from stack slots (it's also ILP32 with the `long long' C data type only making proper use of the full width of the CPU registers, while Alpha's --taso ABI is I believe IP32 (?) with the plain `long' C data type still 64-bit, just as with the regular LP64 ABI). This saving turned out quite important for some MIPS applications; less so for the Alpha, where indeed it was mainly a portability matter at the time when going beyond 32 bits (and writing clean code in the first place) was a big thing for some people. Maciej