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 1F374C47258 for ; Sat, 20 Jan 2024 06:13:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D2916B006E; Sat, 20 Jan 2024 01:13:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3829E6B0071; Sat, 20 Jan 2024 01:13:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2556B6B0072; Sat, 20 Jan 2024 01:13:36 -0500 (EST) 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 11F536B006E for ; Sat, 20 Jan 2024 01:13:36 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AF000140190 for ; Sat, 20 Jan 2024 06:13:35 +0000 (UTC) X-FDA: 81698672790.02.22A7523 Received: from out162-62-58-211.mail.qq.com (out162-62-58-211.mail.qq.com [162.62.58.211]) by imf24.hostedemail.com (Postfix) with ESMTP id 3C6B3180011 for ; Sat, 20 Jan 2024 06:13:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=YzN0zauN; dmarc=none; spf=none (imf24.hostedemail.com: domain of cyy@cyyself.name has no SPF policy when checking 162.62.58.211) smtp.mailfrom=cyy@cyyself.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705731213; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FSgOORcQO5lgUOwo8yV1k/rvCE07D2OesQo7olHJxB8=; b=MDkPy81hBgYUoZlPmJiMgVBHk/YUYGJ8dyTfiIBaLO1TjVxhIQBuc++TuFvyG7DSBTB/CH pakeppgHwL0pkZtGpJrxhxDmJJTw7P8Y09pV48GbPr3hy8mbXaHrjmOEQruMHELsAdOqPu ShsI8EWO+RKkRrgTEvJZB6fGwcvvemQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=YzN0zauN; dmarc=none; spf=none (imf24.hostedemail.com: domain of cyy@cyyself.name has no SPF policy when checking 162.62.58.211) smtp.mailfrom=cyy@cyyself.name ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705731213; a=rsa-sha256; cv=none; b=cd/mRi70NfbQT7DGpJ/3Usd4E4PDmHRZYIF5ER2rkh1gOVZd+9JzzfRfe6LjjRFBBK+9wz 5sGD2rywPVHvMV/ydBEkXAobSV7KQFgZvdnn/zW5iujlAFDmn/xoGOcPy+cIKCg2u5ArdC DwIdKEhQTz/Jj0gxvvAIHxDXV4jB74A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1705731198; bh=FSgOORcQO5lgUOwo8yV1k/rvCE07D2OesQo7olHJxB8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=YzN0zauNxX9cLlvoYg3pwxp7zPr+zI6NOUt8z0TAMLqR7LYOIhknlplcnGncy6gL4 3WNKF3gXTekjjPxY2w9TeVYF87K2RsbYX0LUaQVQYwej5+r/d5MGvybgSWi3enilyX niLDajg0+QLqU4+eg3w3VZ9Y/3dzhXzJVxwUZj/4= Received: from [IPV6:240e:379:227b:4f00:cd09:8a0a:600e:c38] ([240e:379:227b:4f00:cd09:8a0a:600e:c38]) by newxmesmtplogicsvrszb6-0.qq.com (NewEsmtp) with SMTP id 34E26442; Sat, 20 Jan 2024 14:13:14 +0800 X-QQ-mid: xmsmtpt1705731194tluox7vxj Message-ID: X-QQ-XMAILINFO: NmRjDopJZVxOa26de14HAXFoYHQ08j8Qs7V+SVV1ET7ciwxp9PLNUzI2cE9Wef JrxZSkfaZRH2wlaa99VkKVAYrKXHu81wW84VPVtM+5epuQxmeSU3dP+DZ57h3v6U9zBUF+Lc17U1 OMU1JxUx/NQSR6AonfLKr2piq76uQC9qAMyeZIwJDhx2rYdLAnP+DH7dxnv/Ak17+EyLH0uDUw00 Y+uvvIOm7OswqTOf5XWyhoEdJRulUGT55UYuaUz8YsFIl8HRCOaYJF2e39+dCtDVpl5S7YVbOybp X85jc94s0oV+5ODm73hLQWxP1eQRDlZbbwXWViKsDf12XLH9r0RqdDbNstKYiw6ZK2ju+LsgFBzQ wiwvBvCT4cVrv+z0WpbAMDP/ea1Xd1HC7edRVnSYrXgEIv1uHE4v8DUeGwB1BcoKN40kfyQp+Uk1 aTHzCghkVl9518xsgeizUuEZqIy8xghrdB4Zqa/ay+EVPJjEHgCvTUjUXbv+R+CnKyBft6zhgqXd dT9E20V3Xeboyfpz345GPnXr1vXMPafyfqixTWXlDq2YKt83amMGKJjfPkhGQNVnNsazXXXaFb6l NKhy6mt3aQpqbvU3Wm6pN9Lc9pYRBqa9CAJ3Y/sodWZAlQgTxROw8vSq8ZIzjDmv87CYXBAccb5J YTsTVvXcAKscFKTdrmtbhd22jD+goO1q50QsJS1UrHur5z6C9BSQTZ16uQZlUvJqn/Mrmtm0T/NZ ajunfU/gCEDC3AQ8fiH+bfg8hjzDi2KoF4SYEu1+YKXwSz1AQ6jotwLFMoVVeO5tlYVZ1yERuI2S fD+NvLiVc1O2S83eSRdH3vsm5i8nIJFljhyE2tjwZjGfcPj/Uq++mrQQXRWtPUGCiH1a6b2y4+EE DeP4b+e1PljbZHlr+C2j3NvUM20adqTXEJ+h0FinfDveFc4uMJsK1fsVWhGCw7gYxgHE/k8ose6g lMbVPBhrwW0Z32xxN8W9j934P0aX02 X-QQ-XMRINFO: Mp0Kj//9VHAxr69bL5MkOOs= X-OQ-MSGID: <1ee2f17b-4cd2-41c6-89c3-6842d87e03ce@cyyself.name> Date: Sat, 20 Jan 2024 14:13:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 0/4] RISC-V: mm: Make SV48 the default address space Content-Language: en-US To: Charlie Jenkins Cc: alexghiti@rivosinc.com, anup@brainfault.org, aou@eecs.berkeley.edu, conor@kernel.org, jrtc27@jrtc27.com, konstantin@linuxfoundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, mick@ics.forth.gr, palmer@rivosinc.com, paul.walmsley@sifive.com, rdunlap@infradead.org References: <20230809232218.849726-1-charlie@rivosinc.com> From: Yangyu Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3C6B3180011 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 8b758bgiq4zeqnbefo4io1za3tc61jxo X-HE-Tag: 1705731211-326015 X-HE-Meta: U2FsdGVkX1+DTks1GOAo3MW2OKXTC4Larg2Cn/zAQkN50T/cWNCMzIkyD9B0pIme6qCBAVOop9Rjk/2Tqy5iqfz0O43vYW71Jk881+PAYwLxrOupxezvjEE32SrjFLfDa6SUXOhAS5XlBYkzoJfC/2tTjiEwGUny81a/korpIb804AB6S8ZBwlXOjeM9gTz9o5ngkUMnL5RRUqbXFNj05GCLZOrPYmJF2+KLYnz9YZAFN8hJp1mSbTJI3PxcvEWkP5BlMXQuxe3mphYBEcHCRr0SYN+fy5Jw6JnCsUohaSrkZpjfPgXJg43IDcwd9VGCISTN28medG5ejpvIz9bumRsexi9+8r9k20i9OT6P6v8DMmaHeowCLsZnC0b3buulaOv52CZYdWL5DmqO0yEQwQVS0myyvhL9YfRarhuERjRAin9094ru8YDfVwZmx5DQ0HlDGvcOvPSuDieJVLNyUxSlhM8znaS29/lKYdzq/Dv+6I14NQZx4Ysb4DBKP4KGeGBGNzERc1JiijDexxlcdat+mNSQK+yUUX+pYGB0jnvkriX5cypoq6SaMsEptI/yvdc92whdZF/1LCinABTECmf3ORW8s6RNajnHZJKU/kRg+FM1lMenBWNyAp0wkfHzg2tHTzJu2iMcL/pPDTTbX4891uYO6xfjAlfYw0Ug+Pco2NZ08rl9sZlBGG7fEPNH2sZW6S1wwO/MZKeS1eaKeijwodpPtpwBsZC3o4xqpxU9b409FpKdrgBJVYMVEUx3w1z9nGgLeaiUgb44DiaOsei90dSdTFnnHccVrnOxHUf9dF/Ol5ZJhf5dHx302KnGE6iT82kfamk2OX7epWAhCg3KaxDvuy3PuQpn+o6ogL0MuliMAmAZy1b6juaGOIYd+ysIr45Y4ZSd+cafe66XlAcIVR4Sm+3Lq/ZHdReIYjE1yWkOxcZOHHkhk0u2TLN5VgpN/Ns4H3ylvV5gKqL aNLEIltj 17K6k3eWLVZEvZ+fUuQeLW8A/rJsG2PXNlhjNUD2x2sgSj1iNLqJnKlljslH9Kxu/ljm3lPMTiVIH9d3Y57ccamToaJt6KG569IbArxl9kICd7f0crRBzXfI90tP/l4a8i/aGc+f8Srbhd4ss9kNUqVlElpdRvAeQi5ugQwCSfFumeTQYXiaa/tqhwVOUuxIf4uWfKt5aWG8RNQDS2SuwK1VByQqWZp9uvccC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000238, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Thanks for your reply. On 1/20/24 09:34, Charlie Jenkins wrote: > On Sun, Jan 14, 2024 at 01:26:57AM +0800, Yangyu Chen wrote: >> Hi, Charlie >> >> Although this patchset has been merged I still have some questions about >> this patchset. Because it breaks regular mmap if address >= 38 bits on >> sv48 / sv57 capable systems like qemu. For example, If a userspace program >> wants to mmap an anonymous page to addr=(1<<45) on an sv48 capable system, >> it will fail and kernel will mmaped to another sv39 address since it does > > Thank you for raising this concern. To make sure I am understanding > correctly, you are passing a hint address of (1<<45) and expecting mmap > to return 1<<45 and if it returns a different address you are describing > mmap as failing? If you want an address that is in the sv48 space you > can pass in an address that is greater than 1<<47. > >> not meet the requirement to use sv48 as you wrote: >> >>> else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ >>> mmap_end = VA_USER_SV48; \ >>> else \ >>> mmap_end = VA_USER_SV39; \ >> >> Then, How can a userspace program create a mmap with a hint if the address >>> = (1<<38) after your patch without MAP_FIXED? The only way to do this is >> to pass a hint >= (1<<47) on mmap syscall then kernel will return a random >> address in sv48 address space but the hint address gets lost. I think this > > In order to force mmap to return the address provided you must use > MAP_FIXED. Otherwise, the address is a "hint" and has no guarantees. The > hint address on riscv is used to mean "don't give me an address that > uses more bits than this". This behavior is not unique to riscv, arm64 > and powerpc use a similar scheme. In arch/arm64/include/asm/processor.h > there is the following code: > > #define arch_get_mmap_base(addr, base) ((addr > DEFAULT_MAP_WINDOW) ? \ > base + TASK_SIZE - DEFAULT_MAP_WINDOW :\ > base) > > arm64/powerpc are only concerned with a single boundary so the code is simpler. > As you say, this code in arm64/powerpc will not meet the issue I address. For example, If the addr here is (1<<50) on arm64, the arch_get_mmap_base will return base+TASK_SIZE-DEFAULT_MAP_WINDOW which is (1< DEFAULT_MAP_WINDOW. The corresponding behavior on RISC-V should be if the hint address > BIT(47) then use Sv57 address space and use Sv48 when the hint address > BIT(38) if we want Sv39 by default. However, your patch needs the address >= BIT(47) rather than BIT(38) to use Sv48 and address >= BIT(56) to use Sv57, thus breaking existing userspace software to create mapping on the hint address without MAP_FIXED set. >> violate the principle of mmap syscall as kernel should take the hint and >> attempt to create the mapping there. > > Although the man page for mmap does say "on Linux, the kernel will pick > a nearby page boundary" it is still a hint address so there is no strict > requirement (and the precedent has already been set by arm64/powerpc). > Yeah. There is no strict requirement. But currently x86/arm64/powerpc works in this situation well. The hint address on these ISAs is not used as the upper bound to allocating the address. However, on RISC-V, you treat this as the upper bound. >> >> I don't think patching in this way is right. However, if we only revert >> this patch, some programs relying on mmap to return address with effective >> bits <= 48 will still be an issue and it might expand to other ISAs if >> they implement larger virtual address space like RISC-V sv57. A better way >> to solve this might be adding a MAP_48BIT flag to mmap like MAP_32BIT has >> been introduced for decades. >> >> Thanks, >> Yangyu Chen >> > > - Charlie >