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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AA84DC5472F for ; Tue, 27 Aug 2024 16:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=f17LyaAG8TtIxHXQ2Co7Vk2YG66k1jcP8uOLusvEMfw=; b=FEkpNKxBiPF9CY cLa8D2Zl46bBU9eUzUtW4ZtX2BfiD973idTDrTn6qEWj2PbyRXEriGBGV7kjZgXj9NYaEv2+0OOxl 9sB/XrzgSRD5sQgGUXXiOi7DndfgJRk7YYN26iGWEn2x/kR2Bt0S2I9cO3lPW56AXueUzWbKG7x4M IzObPI+umnTpC72Ma1n7ZWvaztAN8Nr5m+GbbvF6PJ8ASupD4IZ5eCtM2u6p2i8OfEf8bxLM15cze apu1/C8gPFTHJ597aM8d2No/WeLipKjXZsXQ+Qh0dIfymrhYJvQKGp9Dk9ZS1Pcey+D+0d5mhvSww DvCmrRUVKX1nuWviUZsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sizFO-0000000C6k0-3x8X; Tue, 27 Aug 2024 16:40:46 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sizFL-0000000C6jM-0Y4J for linux-riscv@lists.infradead.org; Tue, 27 Aug 2024 16:40:45 +0000 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-7141b04e7a3so4705760b3a.3 for ; Tue, 27 Aug 2024 09:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1724776842; x=1725381642; darn=lists.infradead.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=rne+zpysSkg2L5/AJ4St1hJj9zp6Pm7sVmKolecYhts=; b=E3yqgNrMIOcWXPiiyItbK83EYQ0fByBa3tbX5ncCcUMxM5PI5HlJKZTo4bOTLPIXDS +5McIziErRA/iDtGTOVkZ4lKZHmkj/BnQNEjhqzM7WzEhNmV1B8FRaJl71xQ7kpNw2tb KdDUv6k7hptlnVEYqDXzk0rzPacSEuP8u4S6wGQF54hvjjyPto5rx8Fjdi9GygOnwjLT 97qq9aBFLVDRCXyW0LB4Ep96KYb3DnhG+gestalsCeMMismjWbi+m84VEO6aZtpynaW4 CaBIRkcmG0rQjMKFvXvLlZsr2e2tmGlqzM6JX0GVk7CJe9pyxbx5Mel3km/FdV9AcWfo YgRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724776842; x=1725381642; 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=rne+zpysSkg2L5/AJ4St1hJj9zp6Pm7sVmKolecYhts=; b=wL29kxjCFoESs40nNIrZzld7ypFFV533ldkSSWlp6bLDKl3+QtimuKWEINnZP28dyD Jo+JlKs175Hcum1vEQ1Cnmk4kMPK0uNjA6jOly+1ZWyNX/EwoyXSIdiZ3HX7yCWtcMBI 0v0PK50aKgRmEG8JfK20WAy61BsjCSQg0ZXks0isNGZwDcDQCXONImecoNRyXauxi4by FdQaT6yJVvIYkIlMKi2Aepk19Q60KYEFoNdsfA0wCRW9XqS0qQmyEGy+qHOac6mX42qK fITuMJGWJhz5gAr2rzCI6+ssZSG83vB/eTba7lGacPFTxTBtCJ/by6NdMzG4GzwbT2B9 jqFg== X-Forwarded-Encrypted: i=1; AJvYcCWs/DwM3f7lok0gwR3AcsAtGl8qARQy4T87mYnp6sY82t48j4ShihBk8aXt4cOun54kFOFa151p8FSHBQ==@lists.infradead.org X-Gm-Message-State: AOJu0YwgYKa7IMSrpzuiHg6/0e/LKmiY5vt7d+wLDU+dAg7S7YV2kKwp vDjkDdb3z5ncTQMoATaGKHvJGCDqLWN+ixDqEtD3mQveD11WP/WRXRQSFydNoh4UEr9g7PNuz1o 4 X-Google-Smtp-Source: AGHT+IG4PEytdJ7OVt7Zz6RxwZUGrSYdw900Upp1JNyJAzmPqshX0Vt1KaedOXWDN98/VzACJx3dKQ== X-Received: by 2002:a05:6a20:d510:b0:1c8:d4d4:4131 with SMTP id adf61e73a8af0-1cc89ee5940mr15116375637.40.1724776841470; Tue, 27 Aug 2024 09:40:41 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-714343060e1sm9090279b3a.149.2024.08.27.09.40.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2024 09:40:40 -0700 (PDT) Date: Tue, 27 Aug 2024 09:40:38 -0700 From: Charlie Jenkins To: Palmer Dabbelt Cc: cyy@cyyself.name, linux-riscv@lists.infradead.org, corbet@lwn.net, Paul Walmsley , aou@eecs.berkeley.edu, shuah@kernel.org, rsworktech@outlook.com, alexghiti@rivosinc.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v3 0/3] RISC-V: mm: do not treat hint addr on mmap as the upper bound to search Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240827_094043_198792_26649285 X-CRM114-Status: GOOD ( 40.92 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Aug 27, 2024 at 09:33:11AM -0700, Palmer Dabbelt wrote: > On Tue, 27 Aug 2024 01:05:15 PDT (-0700), cyy@cyyself.name wrote: > > Previous patch series[1][2] changes a mmap behavior that treats the hint > > address as the upper bound of the mmap address range. The motivation of the > > previous patch series is that some user space software may assume 48-bit > > address space and use higher bits to encode some information, which may > > collide with large virtual address space mmap may return. However, to make > > sv48 by default, we don't need to change the meaning of the hint address on > > mmap as the upper bound of the mmap address range. This behavior breaks > > some user space software like Chromium that gets ENOMEM error when the hint > > address + size is not big enough, as specified in [3]. > > > > Other ISAs with larger than 48-bit virtual address space like x86, arm64, > > and powerpc do not have this special mmap behavior on hint address. They > > all just make 48-bit / 47-bit virtual address space by default, and if a > > user space software wants to large virtual address space, it only need to > > specify a hint address larger than 48-bit / 47-bit. > > > > Thus, this patch series change mmap to use sv48 by default but does not > > treat the hint address as the upper bound of the mmap address range. After > > this patch, the behavior of mmap will align with existing behavior on other > > ISAs with larger than 48-bit virtual address space like x86, arm64, and > > powerpc. The user space software will no longer need to rewrite their code > > to fit with this special mmap behavior only on RISC-V. > > So it actually looks like we just screwed up the original version of this: > the reason we went with the more complicated address splits were than we > actually started with a defacto 39-bit page table uABI (ie 38-bit user VAs), > and moving to even 48-bit page tables (ie, 47-bit user VAs) broke users > (here's an ASAN bug, for example: > https://github.com/google/android-riscv64/issues/64). > > Unless I'm missing something, though, the code doesn't actually do that. I > remember having that discussion at some point, but I must have forgotten to > make sure it worked. As far as I can tell we've just moved to the 48-bit > VAs by default, which breaks the whole point of doing the compatibilty > stuff. Probably a good sign I need to pay more attention to this stuff. > > So I'm not really sure what to do here: we can just copy the arm64 behavior > at tell the other users that's just how things work, but then we're just > pushing around breakages. At a certain point all we can really do with this > hint stuff is push around problems, though, and at least if we copy arm64 > then most of those problems get reported as bugs for us. Relying on the hint address in any capacity will push around breakages is my perspective as well. I messed this up from the start. I believe the only way to have consistent behavior is to mark mmap relying on the hint address as a bug, and only rely on the hint address if a flag defines the behavior. There is an awkward window of releases that will have this "buggy" behavior. However, since the mmap changes introduced a variety of userspace bugs it seems acceptable to revert to the previous behavior and to create a consistent path forward. - Charlie > > > Note: Charlie also created another series [4] to completely remove the > > arch_get_mmap_end and arch_get_mmap_base behavior based on the hint address > > and size. However, this will cause programs like Go and Java, which need to > > store information in the higher bits of the pointer, to fail on Sv57 > > machines. > > > > Changes in v3: > > - Rebase to newest master > > - Changes some information in cover letter after patchset [2] > > - Use patch [5] to patch selftests > > - Link to v2: https://lore.kernel.org/linux-riscv/tencent_B2D0435BC011135736262764B511994F4805@qq.com/ > > > > Changes in v2: > > - correct arch_get_mmap_end and arch_get_mmap_base > > - Add description in documentation about mmap behavior on kernel v6.6-6.7. > > - Improve commit message and cover letter > > - Rebase to newest riscv/for-next branch > > - Link to v1: https://lore.kernel.org/linux-riscv/tencent_F3B3B5AB1C9D704763CA423E1A41F8BE0509@qq.com/ > > > > [1] https://lore.kernel.org/linux-riscv/20230809232218.849726-1-charlie@rivosinc.com/ > > [2] https://lore.kernel.org/linux-riscv/20240130-use_mmap_hint_address-v3-0-8a655cfa8bcb@rivosinc.com/ > > [3] https://lore.kernel.org/linux-riscv/MEYP282MB2312A08FF95D44014AB78411C68D2@MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM/ > > [4] https://lore.kernel.org/linux-riscv/20240826-riscv_mmap-v1-0-cd8962afe47f@rivosinc.com/ > > [5] https://lore.kernel.org/linux-riscv/20240826-riscv_mmap-v1-2-cd8962afe47f@rivosinc.com/ > > > > Charlie Jenkins (1): > > riscv: selftests: Remove mmap hint address checks > > > > Yangyu Chen (2): > > RISC-V: mm: not use hint addr as upper bound > > Documentation: riscv: correct sv57 kernel behavior > > > > Documentation/arch/riscv/vm-layout.rst | 43 ++++++++---- > > arch/riscv/include/asm/processor.h | 20 ++---- > > .../selftests/riscv/mm/mmap_bottomup.c | 2 - > > .../testing/selftests/riscv/mm/mmap_default.c | 2 - > > tools/testing/selftests/riscv/mm/mmap_test.h | 67 ------------------- > > 5 files changed, 36 insertions(+), 98 deletions(-) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv