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 945DCEE01F1 for ; Wed, 11 Sep 2024 00:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1711B8E0009; Tue, 10 Sep 2024 20:45:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C5978D00E2; Tue, 10 Sep 2024 20:45:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E58B08E0009; Tue, 10 Sep 2024 20:45:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C67E28D00E2 for ; Tue, 10 Sep 2024 20:45:17 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7148C1C3AA9 for ; Wed, 11 Sep 2024 00:45:17 +0000 (UTC) X-FDA: 82550613474.19.3D4EDE3 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf03.hostedemail.com (Postfix) with ESMTP id 84B3B20019 for ; Wed, 11 Sep 2024 00:45:14 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Yp0CAZ7m; spf=pass (imf03.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.179 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=1726015411; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=N9UqXwHRW6ngdlKfPJV8zADUN4nB1bOhg7HrFQqhnhI=; b=68AKnhbkl5BRzTclXT9e4OM9NIMgIa99nX3I4G2QEeh5frTUJS4FTY3HLvC8XAypXORE7L k3piLl89mAm/1BgBG2cPVd95ndY4VqkwRQMSIQGjsa45ujxMHsiCvY6c2Jj+SJfLI5Hj+O p23KEs+ukpPtKo6yGfxS8roa7pc+uLE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726015411; a=rsa-sha256; cv=none; b=raB7WxFBtyqcNLKCYnpyKcmpS9qMrwK6Qj9g1ekmcl6ynL86nmZwiuBUeYjk4GsTfo045k Eep1uAjZqkRhigkYqB61FHEm97C9YzKKiopsfx5ELjuYe9HZ2gim33RXTv8x2sztsi4KbC C3sCoV51umDfdmQRN70+QlxFWwO5JP4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Yp0CAZ7m; spf=pass (imf03.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-206aee40676so51145915ad.0 for ; Tue, 10 Sep 2024 17:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1726015513; x=1726620313; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=N9UqXwHRW6ngdlKfPJV8zADUN4nB1bOhg7HrFQqhnhI=; b=Yp0CAZ7mV0KuKGlnMY90kz3AP1H1wbRKjs3DlKzddJkrC//jn6a0bfScuGUnNi21fj 2XkR9QixByG5+sXROD9Rgn02uOsyXen1+5UawHnbiTYXLNA9U5lGk8uXPjpS7WcMZGT1 +UT3N3A1URitp619gyh1tEwFOFyUKFZNgyGYjRvAnlZxmMGUyksgIdg1diAoX2JOtaOX 8g7DwlHaTAydm/Bsu8XezPujprOSOu4/hNEcEO2Mo/xPuHz6MpJBIBkpFLnsWedUKA3m V7GnSNZpRKkUmConOr0lIZEYJ3TqkiwijMlxq7RLTeRr5c4ZViL3rVBNwt+UNSMTHoMU +9AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726015513; x=1726620313; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N9UqXwHRW6ngdlKfPJV8zADUN4nB1bOhg7HrFQqhnhI=; b=mOufucPG0QIcNiubqF0cWI6ieIoV0KEp/QP/xAFsNwPiVNnssZpRoei4l4sgmeb4VC 4Huy84O2WKmi2a6Y/3G9OuG7ddNDdOifRebdBje+bM+GxPbnBoOUaTUuzGBI0Hg6sWfK YO6zWYmHFBhp9uwtcPhhF6SoFfRrmN/zCkwqzmLRgezeTN8mjcu5Np0/FYFG5XfSVb+D Wka2ZHVBart8gZxa4fc/9r4Y3eFtsc+Nn2ur+o31Ot01vKQtBnjjRaNxTPIUtlssOtPv qmURINu6T9qSjSqz0IXWUmZTlocsMHIiaVYw5kKFQo9ea+BoB1+9eay5wIouJCBDq1i0 TC4w== X-Forwarded-Encrypted: i=1; AJvYcCUddUYsMPY/dx1Eq3WnxjH/AY26f9xVxZNsHPlNqQtWf8wYjaL/lEFxekq9FDYXtd54jx4ejxtE0w==@kvack.org X-Gm-Message-State: AOJu0YwNIloyKTPIrz3ZBzit8IHPuVn85FVuOCM1ABKZ/9ZnPIHvNQxl n84PBYcAKW7uxIJChNr5HFs7t5h2wwQx/qXcjYGfuyYNAlGgRbni6Jf5zG+7H1E= X-Google-Smtp-Source: AGHT+IFSjrtRoDoL7sPwVRBWFNV85MfE4DpNXnElb7X54mGXN2iqCTI2uhxpyL/CAIcKh7QAswSthg== X-Received: by 2002:a17:902:d2ce:b0:205:5427:2231 with SMTP id d9443c01a7336-2074c6a338fmr45444085ad.47.1726015512680; Tue, 10 Sep 2024 17:45:12 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20710eef1f2sm53832165ad.145.2024.09.10.17.45.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 17:45:11 -0700 (PDT) Date: Tue, 10 Sep 2024 17:45:07 -0700 From: Charlie Jenkins To: "Liam R. Howlett" , Catalin Marinas , 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-0-3cd5564efbbb@rivosinc.com> <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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 84B3B20019 X-Stat-Signature: mfxweebt7f5kyaycf6an7pdmrix45smd X-HE-Tag: 1726015514-18590 X-HE-Meta: U2FsdGVkX1+vBDi3BttYZfeZhSss4m2pU/PY5tltv4btcIoSGotBICC/nNNCGGLYW7yi6NI8YxG/LWCYPEFZsviplnrbjPU8I1WiWg+hP0BTahbZnkwHmdGVGSbmZopAnKWDAPlzYD8AjYfMHyADpaWQjsyRv3WcfBmGXFQ6m00e7xsoGm5mPIjBXka0PBCr1wo6/XxlLI9av5LxuNb1gWwKLBvegO0iDkdTUqaza4hEiCUomhXryxERKM31VeQX5pL5Cz70GIJPERviA6XsGb3Skt1z65mB4HwLN9qeaIVeaYKJ2/A5WDwDKgZUdzlBLCbr7XCKylKRflY87/gBNFZDW4L94jgThcaF3EU/IGcHiDyhC3Wsb23L98W+qqeCSqp+/nFf4vyb5eyr7E01sQ1/zIRILdn2FdHJT91x9zilwkk+b6BrM9ZiHARJt/+lPLcanUK2uouZdGd4vVAKJhoStmUP1pKXHZkOHkBM3RTQCI2zP6oFj5EguN+WeX+SGSGQoUU9p2p5L7FpeMEcFy6EciH4K9nuIpXlcFMEA6inaY+ZfDlmgKuk4BrFbSqdcxkBeuutz80DF+unekb6uPFr76Zgv7oqVEaaEEzeuB8uK0KcLrClgx8uVqJMJXgvptXFDpkjMaA26sN42NcH12lHIFg9dXfWOBN0lkGKVJcJVfGKQhH0DoqOdmriiMzVloadrhC/fT2XmEua7aNPik8939UGIGQce6edNDDxU3+7A0lqdK3yxwPRKGUO1dTf70VxvPtIxBgEPlWSv8c1WWuCjh6nCx/zh1L6S/dSGej5tmWCbQZMliu78t/avChXbZlRtfkmdiGzzUAYCL84vR0ug1RmyFwnwDgBvY/mYjkxCHo02VGphtpDTdgIVZbywZ8o6Wo5NwpxZLaJDz4EOhfxxt7DSE3XcMz4KgM/v1De5OQjxhVsYKMbGkeUotcaZ8iut7L7MCeNZQzqDl8 yDrJveKL l9wNGO7AmalkPJTCDjcSNrTfqQbyKM+WE8QcuuJtQDyIGEwzCOEPb7oMDNcyWLQiMvZ2CAk8l9uJLJxUu7cOzVCB8wY9w2TqQjRaw0WHOyj5o9a7/FvWn2KAalx6hozmLiuEA99GsXd34sVL8//mbJ2G+LGtSWxMuHVBKeHh6pNTNd8HEXDlbgJm7ZvcwaOOhlbPbsp767U5uQdxmkqx4pd+EawpywNbLpJ4YCsjHGhInPyyUnhdvajrz7exX22ldFls87/tqgl95L5vqxOJxyEjXNKPNjM+b4mSD63viafVCjxk0yp4tjACLRUG5P/jvuIjfRcfIWbVVQPGTbWCVq9KpVJsMhc4oevcxBenptsEsxsj5L5RzRI6c8r89xdQGXRI0+Wy3i9VDAzkIrnYihyppDgBxWxqKf2TdGh5aIQ4hpLwOR4pD+UCtSyaXoiyLd7uKY5Km5ZS5AEvrI386wl2FvVJcWUcP7Pvnp1pxqXEpHLg1RV5DXmlo/6qE9iOi0D2eccyPub3qyDtnmjK1aOI7KA== 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 03:08:14PM -0400, Liam R. Howlett wrote: > * Catalin Marinas [240906 07:44]: > > On Fri, Sep 06, 2024 at 09:55:42AM +0000, Arnd Bergmann wrote: > > > On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote: > > > > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann wrote: > > > >> It's also unclear to me how we want this flag to interact with > > > >> the existing logic in arch_get_mmap_end(), which attempts to > > > >> limit the default mapping to a 47-bit address space already. > > > > > > > > To optimize RISC-V progress, I recommend: > > > > > > > > Step 1: Approve the patch. > > > > Step 2: Update Go and OpenJDK's RISC-V backend to utilize it. > > > > Step 3: Wait approximately several iterations for Go & OpenJDK > > > > Step 4: Remove the 47-bit constraint in arch_get_mmap_end() > > > > > > I really want to first see a plausible explanation about why > > > RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW > > > like all the other major architectures (x86, arm64, powerpc64), > > > > FWIW arm64 actually limits DEFAULT_MAP_WINDOW to 48-bit in the default > > configuration. We end up with a 47-bit with 16K pages but for a > > different reason that has to do with LPA2 support (I doubt we need this > > for the user mapping but we need to untangle some of the macros there; > > that's for a separate discussion). > > > > That said, we haven't encountered any user space problems with a 48-bit > > DEFAULT_MAP_WINDOW. So I also think RISC-V should follow a similar > > approach (47 or 48 bit default limit). Better to have some ABI > > consistency between architectures. One can still ask for addresses above > > this default limit via mmap(). > > I think that is best as well. > > Can we please just do what x86 and arm64 does? > > Thanks, > Liam I responded to Arnd in the other thread, but I am still not convinced that the solution that x86 and arm64 have selected is the best solution. The solution of defaulting to 47 bits does allow applications the ability to get addresses that are below 47 bits. However, due to differences across architectures it doesn't seem possible to have all architectures default to the same value. Additionally, this flag will be able to help users avoid potential bugs where a hint address is passed that causes upper bits of a VA to be used. The other issue I have with this is that if there is not a hint address specified to be greater than 47 bits on x86, then mmap() may return an address that is greater than 47-bits. The documentation in Documentation/arch/x86/x86_64/5level-paging.rst says: "If hint address set above 47-bit, but MAP_FIXED is not specified, we try to look for unmapped area by specified address. If it's already occupied, we look for unmapped area in *full* address space, rather than from 47-bit window." arm64 on the other hand defines this as only being able to opt-into the 52-bit VA space with the hint address, and my understanding is that mmap() will not fall back to the 52-bit address space. Please correct me if I am wrong. From Documentation/arch/arm64/memory.rst: "To maintain compatibility with software that relies on the ARMv8.0 VA space maximum size of 48-bits, the kernel will, by default, return virtual addresses to userspace from a 48-bit range. "Software can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter that is larger than 48-bit." This is an inconsistency I am trying to solve with this personality flag. - Charlie