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 D3E30EEE266 for ; Thu, 12 Sep 2024 21:16:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71A106B008C; Thu, 12 Sep 2024 17:16:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C8886B0093; Thu, 12 Sep 2024 17:16:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 569AB6B0095; Thu, 12 Sep 2024 17:16:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3487A6B008C for ; Thu, 12 Sep 2024 17:16:08 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E6763140822 for ; Thu, 12 Sep 2024 21:16:07 +0000 (UTC) X-FDA: 82557343974.25.F41634D Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf02.hostedemail.com (Postfix) with ESMTP id 1625F8000D for ; Thu, 12 Sep 2024 21:16:05 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=oACUuhAs; dmarc=none; spf=pass (imf02.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=charlie@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726175649; 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:dkim-signature; bh=GAySjmj1C8RnCc99v/BjFAJ8TYbwKWl+6IomlsR+BoI=; b=b4IJq5C48ykF+Av0qEmP1PSmRJJ0fEQVzl0sE386Q/PR4SemlCfmCkdXsvg+rPQ6VGDfjt wx3MIT8zx3xns7GHTcMXdgEkt/Bch4rSryGOKgIwgRzbaczHTsWNUIPh6zdOCCoU754N/8 GDn9YQoO4jnZe2fBQFEWKIVte0xHjM4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726175649; a=rsa-sha256; cv=none; b=xy4rnvObyAAFXC8dzdGkZiFoCApJ1/Vc6X4g5aDA86FF31b7cHm4KePL1RBBlnwSNt22pg 8BieZCAGZIFEU6BPqnpakDAcAOGqS0wDuKgv4w5ssby2ss3X6SBPo2mOFpIi5KBlflPtYZ sgRFWRaVaN6bPQzlaWVPxOui3DrO2HU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=oACUuhAs; dmarc=none; spf=pass (imf02.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=charlie@rivosinc.com Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-207397d1000so20396505ad.0 for ; Thu, 12 Sep 2024 14:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1726175765; x=1726780565; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GAySjmj1C8RnCc99v/BjFAJ8TYbwKWl+6IomlsR+BoI=; b=oACUuhAsizt969IDzmOAPvSEqRHBWO3sd13FGN3v9HoYLW82ItW9pxdbvfd+IOTMsN T9omMycYZqH1Rnjs8zpAUEFkPS93xmrewaA0sxQfE1NYsHurdavjHCFGwXytiT/BON5J P6xNArblvCSXsmjTOcM27WNE4J2eVGxqtqlSfuMBygFWlk1jy+zEdvyJtNiN59uzY/c4 DvfZBTXQN3mOz86GyokyyNMA9Sg6FGgIVwU8BaQVNaoYRZb1aj1JpQLyoET37iKvh6ML 0mf2PzuNCfg4/BsJCOYZSfbKgcI8Zsoq0soUP+CpHwVmNVKAuwB1fsAG7UjWeZntrZ5V MhLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726175765; x=1726780565; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GAySjmj1C8RnCc99v/BjFAJ8TYbwKWl+6IomlsR+BoI=; b=lWqQzWaQiVWl2EnNQtY55gwESwX3zimWuZmIMjJqUml82usoJqnSIi9tGxYPhK271L VNNj/XQJAbs38J/yntBgSw/xkm6j1mrl+Pk3QWyuGshMdzrcgKSp/wpSrJoYuLTjwjpq 1rOvRmjZwG8mFux2Njl53m6Fgyhqd67zWbKVxSTmfgYHIEX5o4NqTF++9YiFHDNoLC/V fQwYIEpbRPIUR7xQytnmS4F1cki/NFyXGLiq3yPoi8fVDDQ4+KN1kSu87fSKingvZ+A+ aQhCE6ZoN5MjGoyXA1/GO7T5Nu0WS6wixTD7qrVQsZJt8HRN6zJrYYFRsEgJ0kBXn+yF k7kQ== X-Forwarded-Encrypted: i=1; AJvYcCWZyr4h/e8Ziopt7YJOf3GOSnJBR5FLfYgrS7fWNJkBXoICz/85BefCmVjXU4uJgUyxIaa069WLfw==@kvack.org X-Gm-Message-State: AOJu0Yz1tNzu1si6lA/9+kfyFknLfXThOSqWOdWTZTgOfd0ugf6DklZe YcapwySrykhdhxAv3pkNsl85XBprw7zOCRRET+W9LpoyflzWTFfpJPTStGsgXuA= X-Google-Smtp-Source: AGHT+IHUzjdPrj87uHlM3yWrW/J5uo4qx0FxZorL/y/ZhI47SL1dDJtb3OuvF/ucYmZPS3S517PhSQ== X-Received: by 2002:a17:903:41c9:b0:1fd:6033:f94e with SMTP id d9443c01a7336-2076e61ddabmr75358475ad.27.1726175764569; Thu, 12 Sep 2024 14:16:04 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2076af47662sm18233275ad.93.2024.09.12.14.16.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2024 14:16:03 -0700 (PDT) Date: Thu, 12 Sep 2024 14:15:59 -0700 From: Charlie Jenkins To: Catalin Marinas Cc: "Liam R. Howlett" , Arnd Bergmann , guoren , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Huacai Chen , WANG Xuerui , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , "David S . Miller" , Andreas Larsson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Muchun Song , Andrew Morton , Vlastimil Babka , Lorenzo Stoakes , shuah , Christoph Hellwig , Michal Hocko , "Kirill A. Shutemov" , Chris Torek , Linux-Arch , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, "linux-csky@vger.kernel.org" , loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-abi-devel@lists.sourceforge.net Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits Message-ID: References: <20240905-patches-below_hint_mmap-v3-1-3cd5564efbbb@rivosinc.com> <9fc4746b-8e9d-4a75-b966-e0906187e6b7@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1625F8000D X-Stat-Signature: g7pk7k7ex51socb9ooo7435e5m1kueyp X-Rspam-User: X-HE-Tag: 1726175765-882895 X-HE-Meta: U2FsdGVkX18YtW7ovyd0n3gwNY+Q4BZaAk2eeEh0kTkfPJbqH8Stjm/i1tdfdAghWQ5Onfo2AdAKfJstL0EIcsVWUnL+OznvM9m7kR5wlNrFo4vzVT8nfN73t+zcYa6qydw/nTzMCVN3YNM90na2ERPBe421+GyLH9RRGdAA+CBIq15vn7lpw+boGLCHHL7NAUsl+qmLITwiJOcbggJRLhAv2eED0h91kAZryJ61ED2ytEDuUEFaZLTR2qTYtPD2Dk+nkuG8AD2GG/6gSePJ06+8tJ44d7U0+EKG6kdc0ymC52bH+KNKXGG4YGbdupMC7s+auNO6LY8Xiv2H679qu5xJ3SpbEAI4XsdANFZembLvUZ8Ix+qrRfXoPTnX7eBeuE4RSTZ88j0IN2hlzEFIapEEi6EbzIxVHAsFkgfyzRwQ0+Oj2KqcWBTzCCkT7k3UaQ5GLB5624jQerwhAXtwdaekQgQyvSa4AdCnUvVTizzckgHeKDhTIB1bYj534NgaPbrD8RkPDouWrFu720SwJzmWZR509VRFCXhs95rdzHlyYRBWGDfei4WZATYLTsMAPSTj+COxqmvXJUDLQ11cw6a/AxuVIlLMp2QWsSYPfl30KFtyTx63h6OeWKy++9BEZ3EJuLs+OSrCb+Y1bvA/iWv81Na3P7zul1/No2ErHiyc/0hFPER5525hchbSKn7G8k0C1S7SQufJM40WpBWXxONJwuHrpjBxJdCZFunT4gx8tQqKO69+If+Uo9rO4UtWBJLoKsjMHAzLu/rOYy+bVHui8GESM6iglLkh4o4UD48jELWl25USNwikwRZCUN8en4v/gxIf/dJplTPZf5ur1rFO8+pBxFQpVc3NqnyLVAKzJ4yDhL/l7F99TzocM9zPybs3AnJO5e3wb80bBAsq4Pa1QNgt6qS08JB9penNxsNwwsBPpx4CyGuTbjZYnnl9fOgbiDEyWr4xtESExR2 FBi3EPn5 w7DhwtcXp5zUF2m4l981C+byxBAWuaHR2N31NA4jPkdCZGW4mkvfEpGbJE2w4ScKNtOlYX2dRnf3vzUL3zPjMKq/PRdsHCiQPpcg7EI7Du2nwb5mZRxaQ/wjcSffOGK2dBeJFsFYB9c+nTWjICFL53Fh1q0IKw1mNYdpBttS7btkZOfq6GqhodwJomBUx8MRqYxMX0g+A1WB3UgDqxLIpkQP6lt20FKX080zcOSrkZmTJ77IFIN+Kq6R0zaoiHftxpEq11G5XDDxXnLfp9OWjQEeV4qPyADIMpLy7FYMpwX10cBcOtymSmnIx2W5UdA+nr4b6aEDpgor5UXdjZp3rrPeiQgTIvHt/AM1c4o7YAoHX5Yq4BsakMpZGx+oxeJ3RKiM4yqQIFejXjZpoJsa4NAk8z7VlTTu7tn/0fG1OcqVZC90knzehDKxSe3rFbv/iLz4H 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, Sep 12, 2024 at 11:53:49AM +0100, Catalin Marinas wrote: > On Wed, Sep 11, 2024 at 11:18:12PM -0700, Charlie Jenkins wrote: > > Opting-in to the higher address space is reasonable. However, it is not > > my preference, because the purpose of this flag is to ensure that > > allocations do not exceed 47-bits, so it is a clearer ABI to have the > > applications that want this guarantee to be the ones setting the flag, > > rather than the applications that want the higher bits setting the flag. > > Yes, this would be ideal. Unfortunately those applications don't know > they need to set a flag in order to work. It's not a regression, the applications never worked (on platforms that do not have this default). The 47-bit default would allow applications that didn't work to start working at the cost of a non-ideal ABI. That doesn't seem like a reasonable tradeoff to me. If applications want to run on new hardware that has different requirements, shouldn't they be required to update rather than expect the kernel will solve their problems for them? > > A slightly better option is to leave the default 47-bit at the kernel > ABI level and have the libc/dynamic loader issue the prctl(). You can > control the default with environment variables if needed. Having glibc set the 47-bit requirement could make it slightly easier for applications since they would only have to set the environment variable. After the kernel interface is approved I can look into supporting that. - Charlie > > We do something similar in glibc for arm64 MTE. When MTE is enabled, the > top byte of an allocated pointer contains the tag that must not be > corrupted. We left the decision to the C library via the > glibc.mem.tagging tunable (Android has something similar via the app > manifest). An app can change the default if it wants but if you run with > old glibc or no environment variable to say otherwise, the default would > be safe. Distros can set the environment to be the maximum range by > default if they know the apps included have been upgraded and tested. > > -- > Catalin