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 51DF3EE01F1 for ; Tue, 10 Sep 2024 23:29:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A32D58D00C9; Tue, 10 Sep 2024 19:29:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BABB8D0002; Tue, 10 Sep 2024 19:29:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80D158D00C9; Tue, 10 Sep 2024 19:29:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D89B28D0002 for ; Tue, 10 Sep 2024 19:29:20 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 55210160C16 for ; Tue, 10 Sep 2024 23:29:20 +0000 (UTC) X-FDA: 82550422080.18.75055F0 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf24.hostedemail.com (Postfix) with ESMTP id 5878B180011 for ; Tue, 10 Sep 2024 23:29:18 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=H0Xe0h1U; spf=pass (imf24.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726010930; 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=CYrCbXlvqV0+h/8xybyAavYRRnIQ4hnNCNmZGJwr9QU=; b=rcjFoVRLV8st4hJtZ3P43i/8bB65pZNigVxtwA44T/Z4hpX6GDIIbHzHEBnIW/C49Eis4D /9pHvB6GkL8mJA0RrdW99pj5z0A1eclhvUT0XXr/MkRPILfeC9jEl/fRaL7ceSwTA0VgbH k+j5sl7swYp0CRY8mhS14AAx9euY+C8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=H0Xe0h1U; spf=pass (imf24.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726010930; a=rsa-sha256; cv=none; b=ZlQaCgpbNITRsrbA5MIoy3zBTP4Lgb8/bFpq3IxRIJTcP9cFjSp7qiMlcq41KWx/MxbXxs IpQPs4vpHw8sLcqeCcyWRB30h0XsBCr91zmspcgewb0FXDZ/COqGTlNVaflGXI1sZLy71l nlxcOdWbLIhjbs+z93TNyb1FtchepiU= Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-7d4ed6158bcso4309773a12.1 for ; Tue, 10 Sep 2024 16:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1726010957; x=1726615757; 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=CYrCbXlvqV0+h/8xybyAavYRRnIQ4hnNCNmZGJwr9QU=; b=H0Xe0h1UGNT1u6joDUPw3P5H9uvRaRTOvbL1jm2QJWcUr8VwMd8t8tsMMP9FdmEnBK V2Tw1xMyjavHZxG2GbVb9Jf21cx1/CtkwUoquKcOUmK88oj6WoQdFRLhAcFg0ESIpVM8 7ZJf7TtyCyXtVB5WngZylbz6U8QKtftDB5Rdo1azWpRJdMDkRnRA5SRiJD35SLHcT3Ta FT1cwulXu5krfbEt7QlvjFCnU0vYgnEPoqlvvv5FYasnWYkXL6bxJVWzxxwca6PLJYIL TpCyzDzIj6V9jz/JemRTDYcjSAJh2FA+xSSNnXXkpUzQscc4+4BtbHdafZB3Jv5MfetR 6gyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726010957; x=1726615757; 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=CYrCbXlvqV0+h/8xybyAavYRRnIQ4hnNCNmZGJwr9QU=; b=GexDoFPzDso3FrRH41tA4pETuSJqR2HxAHkj6sG/5J+Y+OEL4rAlVp21/fQuJ6sUkv qI249CPaIO8MAbeV0pRaMaRuwxvOSUnEE4qDG53LhELABR/7YzysDDnjlIkqonz9dMbZ vc0BGX9XAJjfvDvB4CLHDbEQ8wIVxkoO/LZY0DQ1JXBS5CHMBtqs0i6FX27C9PoUFpGf P/x+4woQXjejBWVSzb1Qc37DrQ1uQ8smp3WqtANAEEZDhm4pTEQtTEBTXv7avcgeDkOp PS0TPS24RgKvM/7WZnVsVsjGnyFbJAIWTcc0zBCCCOExlHvBI5ou/JFSSSxE2hjTucwz /qCw== X-Forwarded-Encrypted: i=1; AJvYcCVU7oY/Mgz7ks5xo2CvPl/3c/M7gw0i98ZmQkbGtAd7m3w8hXEJ4ZFAgfoSv7plv+FEtwp0U5g0NQ==@kvack.org X-Gm-Message-State: AOJu0Yx1dkNxwSEWvcusdxe+ZShHML/l+4o7xAD0L7Smq6GQT9kNPmP5 mnN46ofaMQW5x08R56tD2QOuvVni9vOAZZ3XQxg9Eq/F3wMG2AYdaxNWZEcr3bg= X-Google-Smtp-Source: AGHT+IFu2ts9QR3o7HId+sTbARvp/Mp4cS7y9d4XxkhhKVfZnTlnktrEfIJSlLrlAVGi3hD8KRDoUg== X-Received: by 2002:a05:6a21:3318:b0:1cc:e4a9:9138 with SMTP id adf61e73a8af0-1cf5e10ea44mr2924283637.29.1726010956374; Tue, 10 Sep 2024 16:29:16 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71908fe2641sm1873651b3a.59.2024.09.10.16.29.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 16:29:15 -0700 (PDT) Date: Tue, 10 Sep 2024 16:29:10 -0700 From: Charlie Jenkins To: Arnd Bergmann Cc: Lorenzo Stoakes , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , guoren , 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 , "Liam R. Howlett" , Vlastimil Babka , 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-0-3cd5564efbbb@rivosinc.com> <20240905-patches-below_hint_mmap-v3-1-3cd5564efbbb@rivosinc.com> <9fc4746b-8e9d-4a75-b966-e0906187e6b7@app.fastmail.com> <58f39d58-579e-4dd3-8084-baebf86f1ae0@lucifer.local> <7be08ea9-f343-42da-805f-e5f0d61bde26@app.fastmail.com> <016c7857-9ea8-4333-96e6-3ae3870f375f@lucifer.local> <89d21669-8daa-4225-b6d2-33d439ebd746@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89d21669-8daa-4225-b6d2-33d439ebd746@app.fastmail.com> X-Rspam-User: X-Stat-Signature: 7ofm4o1y4mro89ig38jdnysh4x9yaupq X-Rspamd-Queue-Id: 5878B180011 X-Rspamd-Server: rspam11 X-HE-Tag: 1726010958-596170 X-HE-Meta: U2FsdGVkX189d0bSSekYgx//M+up1fcfDEHhECJOH8hm1PRNZ82AcBy7zXMfFjhyBGffB/AShsiCfqkmdvf+zUxR2uWFWHUNrSHV2Ak+52DcLEx2vU5/K+GQle0XOvqFdK62M1orB+n+SkpsjoB+8zXefgNmwTEK3hme19wcbY3GsdUZLkaXby3btQR2QMfY2A9M2N7Diqbk2yvIiVvUrEpmpIjhVeg9YHKwx4w/zCU3TapUdIk1/YOSsUYbfRptWQe3Avqo4morbV4AqlT9AGkI68YqRc4lXeJoeI0VBZ0Hc4phP/pMn3JJkWw1ZD7J14lP9ppVkU1O2ckfw2BI96Zmy1iui+xN3TO0NsvUrlGshNIjhoOtPz5OtSJNKYsubAMDjrpKc56k4igJ2GBCoLUlGiVeSFVtOER9HhmabP6MvAm54UV0o2LAKmILKpcGiumeEpGIdYoKBuU9IXAGP+e3B/fyDfl38nt2dDWW5n3VfZX1se7HS+ipSxAQFe5TNXhJcuKTnl7OeHJZteHtJ1vTv9MDhYX41tpldH0b7th1gK5NXO7dHMYMF5c0eIrk7db4E4jLWBBoKrSZFT8xjd+3khjvhDKGVkDCUjexiZa7+siYeQ/RN9QLR3dTGdqQgIIyjCzHCxMmX7sPpm5EG/Q35vqxq04M/ZvLoHLuqpyyi11g1u+xtKlO5/Fq0IKfrvjR3viGNWS2/hHV+cLRAxMrwpZDQnHuJh27Cm0tmZc2VajUCUBny8J04oZ20GIqB8dgTnU9rF+si6VFXIXS0A9H8e+8fcNPe7WBZMk9zukyJ8T1ZSn5/HL64Rq21GaTAkEsuE7SdCAGaHPuE6WDHV4i54hVd3i1egOjOVInB5t+XdK9+pArsiOsZH5fq5w7iBocY2SLW2EbimaLV2jOznbq60koipewDe5TA5RqkBrTUzMHXnUwF2eJHlKca5RVuzfvaeWTDmepuhKEVqS SGxUBX+O BIsmwglAWqYGzkZLEmjdnuRmqehBY7Wl9Hb1hZLDfoGyaqJQDY2Xg0m6OIQjuZHhbyGosIb3H1nOw9/LdmfI9O29o44R5uy+bWPA27dPeKbRyJEQJwk0X4pOUbwWD5saa+Xr/zrCqloV/tm0w0UQYA9Ckv/f+6WG6dMjU6Bu0U+KAyjGHIHm6KPTT9+PDz/JQaSSIpNySBLo/gfCFOF+vtuyOF7hcq4Hub/pAQqGINLnSXU8uDKl2hrcbUWILMxc3Nq4yslkUW9dZBl20yUfzq/Phtzck1FwbnVxTUJ/Pdm4oqLrgYKJ2HaD6xgmPJ2qrRNiveMu5ibrBsUixHwxRYvBwnHixwJwDFI8FKaFDJ6lsrVv/z+fERV/SRG43ECKqxN4XJPMWcYqU9RGqkdO7wd6cL2r8yIxDkOM+20RYJUj5/DQVBof7fceX4fpNQTeLJZ2Raru0aDbuUu9DOZwe6T5nT4tb8Ip79gPI 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 Tue, Sep 10, 2024 at 09:13:33AM +0000, Arnd Bergmann wrote: > On Mon, Sep 9, 2024, at 23:22, Charlie Jenkins wrote: > > On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote: > >> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote: > >> The intent is to optionally be able to run a process that keeps higher bits > >> free for tagging and to be sure no memory mapping in the process will > >> clobber these (correct me if I'm wrong Charlie! :) > >> > >> So you really wouldn't want this if you are using tagged pointers, you'd > >> want to be sure literally nothing touches the higher bits. > > My understanding was that the purpose of the existing design > is to allow applications to ask for a high address without having > to resort to the complexity of MAP_FIXED. > > In particular, I'm sure there is precedent for applications that > want both tagged pointers (for most mappings) and untagged pointers > (for large mappings). With a per-mm_struct or per-task_struct > setting you can't do that. > > > Various architectures handle the hint address differently, but it > > appears that the only case across any architecture where an address > > above 47 bits will be returned is if the application had a hint address > > with a value greater than 47 bits and was using the MAP_FIXED flag. > > MAP_FIXED bypasses all other checks so I was assuming that it would be > > logical for MAP_FIXED to bypass this as well. If MAP_FIXED is not set, > > then the intent is for no hint address to cause a value greater than 47 > > bits to be returned. > > I don't think the MAP_FIXED case is that interesting here because > it has to work in both fixed and non-fixed mappings. > > >> This would be more consistent vs. other arches. > > > > Yes riscv is an outlier here. The reason I am pushing for something like > > a flag to restrict the address space rather than setting it to be the > > default is it seems like if applications are relying on upper bits to be > > free, then they should be explicitly asking the kernel to keep them free > > rather than assuming them to be free. > > Let's see what the other architectures do and then come up with > a way that fixes the pointer tagging case first on those that are > broken. We can see if there needs to be an extra flag after that. > Here is what I found: > > - x86_64 uses DEFAULT_MAP_WINDOW of BIT(47), uses a 57 bit > address space when an addr hint is passed. > - arm64 uses DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), returns > higher 52-bit addresses when either a hint is passed or > CONFIG_EXPERT and CONFIG_ARM64_FORCE_52BIT is set (this > is a debugging option) > - ppc64 uses a DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), > returns 52 bit address when an addr hint is passed > - riscv uses a DEFAULT_MAP_WINDOW of BIT(47) but only uses > it for allocating the stack below, ignoring it for normal > mappings > - s390 has no DEFAULT_MAP_WINDOW but tried to allocate in > the current number of pgtable levels and only upgrades to > the next level (31, 42, 53, 64 bits) if a hint is passed or > the current level is exhausted. > - loongarch64 has no DEFAULT_MAP_WINDOW, and a default VA > space of 47 bits (16K pages, 3 levels), but can support > a 55 bit space (64K pages, 3 levels). > - sparc has no DEFAULT_MAP_WINDOW and up to 52 bit VA space. > It may allocate both positive and negative addresses in > there. (?) > - mips64, parisc64 and alpha have no DEFAULT_MAP_WINDOW and > at most 48, 41 or 39 address bits, respectively. > > I would suggest these changes: > > - make riscv enforce DEFAULT_MAP_WINDOW like x86_64, arm64 > and ppc64, leave it at 47 > > - add DEFAULT_MAP_WINDOW on loongarch64 (47/48 bits > based on page size), sparc (48 bits) and s390 (unsure if > 42, 53, 47 or 48 bits) > > - leave the rest unchanged. > > Arnd Changing all architectures to have a standardized DEFAULT_MAP_WINDOW mostly solves the problem. However, I am concerned that it is fragile for applications to rely on a default like this. Having the personality bit flag is supposed to provide an intuitive ABI for users that guarantees that they will not accidentally request for memory outside of the boundary that they specified. Also you bring up that the DEFAULT_MAP_WINDOW would not be able to be standardized across architectures, so we still have the problem that this default behavior will be different across architectures which I am trying to solve. - Charlie