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 C7287C4725D for ; Sat, 20 Jan 2024 01:34:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C70C6B0072; Fri, 19 Jan 2024 20:34:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3509D6B0074; Fri, 19 Jan 2024 20:34:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F1306B0075; Fri, 19 Jan 2024 20:34:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 08DF86B0072 for ; Fri, 19 Jan 2024 20:34:38 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C896C1C1828 for ; Sat, 20 Jan 2024 01:34:37 +0000 (UTC) X-FDA: 81697969794.02.5F5B943 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf15.hostedemail.com (Postfix) with ESMTP id E21EAA0007 for ; Sat, 20 Jan 2024 01:34:35 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=WwcTO43O; spf=pass (imf15.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.181 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=1705714476; 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=1ESr1s1LQuOTutaWHm69OFuVr1y+EY8ccPvGNNNRU7c=; b=BALOYUi4OFAcX3ZHz7eUwC3bllFYIZVf8tUWwI47ooewhpNplKpzNxQM5H9q2wCBcdqo2l fH2kwm/ViOzmMKCCXu6BxCKQD6OBPlX8WMdzdqoIPt3I6UmSrzzXJn7t1KcPKKdCBCUq7c SgFv1nfsaU5u/D9Gbw3Q93ELb0irU94= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=WwcTO43O; spf=pass (imf15.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705714476; a=rsa-sha256; cv=none; b=Ijto4kcCQOf9/5SDIBU6SevDrP91mIjFc8cc/vjc4dIuIOu0QPvZUhoV2lsHJU9KNrF5cj /88hCcpIWiAvT6xZqDBr73u4mwT3MF+NhOmiNKBuVNyM78Xa2RDOQ3+hcYDWtHd4E7Juri BGoyF/Lkdiei7I8O/n0bj0zuda7RAgo= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6d9a79a1ad4so1214752b3a.2 for ; Fri, 19 Jan 2024 17:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1705714474; x=1706319274; 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=1ESr1s1LQuOTutaWHm69OFuVr1y+EY8ccPvGNNNRU7c=; b=WwcTO43On6K2wgDWWBqHmulci1z4FlNtdYEq7WCc88S1R98Kp/kp4nkO2wYHCPzJMo xEkEG1XWE1iFI/cyP6VJuP9gEJUBj+ruCUc5Nr0VvE00ixLtMoUczDC2ZoZrTsgPJNek e3QOBPHQ5cdrn6GkctbZ9CPUIF8n2Ag5rWE4xkT5VU9wS8M2AOnDw3vqmmu98h5uRbl5 NdiJUAyJxCLNxjUaEEtzj4+aC35scDtWtRI2RPq9KY2EjeagnoKGvr/Ovm+QNagaytic 0wF0pZM94BAzJ5UnmedcrJdRPC09kt2S/Gg5QsTVY7fA3cm3UslR9zYjhEhYov+6lVQC C7kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705714474; x=1706319274; 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=1ESr1s1LQuOTutaWHm69OFuVr1y+EY8ccPvGNNNRU7c=; b=GR7FAFOSsgY5Jg7yoTlnhZRCjaGt+KGUCvjHfPynH4kB1g1n7ImSa4uvtQEx188T8t 61Gxbc1keQTRbB3/6hymxIg5W3C7oLoRYmsbsTHDZRoOA3mS6EBg2oB4+lUC+iLtAi2X ztskuCxS9MNBtjDf512gizDdL/KO8M7E7WsI+zlicfXAIaYn3fYIZH+0Nix1hAv9Bzlj hfO9ZnlRND/pSxI1MzznT5qPueaj00Qf7T1eFeWEytIL7FBoey2f7kXRCae/ttTqDrTC B1LZtESNXm2x/qt+va4GOZ7LFVqLZWrdtVc1NdPGeT9/e2USikh1Ebv/x2nMTDPU7O1v 8YOA== X-Gm-Message-State: AOJu0YzllQoXAMTPfUVLNABBAdoBOGnpglxOH4jjJuT16NtuvhX4y778 abP5pPU/OEK4g0pfYdoJJzg/UxIf9EecJF65CdNSTq8KMA2GwEem4e2LPRYZC44= X-Google-Smtp-Source: AGHT+IFpTaljaK+IhzjIUgqr3GVQ3I9VycDOb1FWOAfJMZG3m5Pa9z8B24GyjvedFp0KN3e6hXYsKA== X-Received: by 2002:a05:6a21:185:b0:19a:6830:2334 with SMTP id le5-20020a056a21018500b0019a68302334mr757399pzb.46.1705714474654; Fri, 19 Jan 2024 17:34:34 -0800 (PST) Received: from ghost ([12.44.203.122]) by smtp.gmail.com with ESMTPSA id r9-20020a170903410900b001d71c89fb32sm1961666pld.269.2024.01.19.17.34.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jan 2024 17:34:34 -0800 (PST) Date: Fri, 19 Jan 2024 17:34:31 -0800 From: Charlie Jenkins To: Yangyu Chen 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 Subject: Re: [PATCH v10 0/4] RISC-V: mm: Make SV48 the default address space Message-ID: References: <20230809232218.849726-1-charlie@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E21EAA0007 X-Rspam-User: X-Stat-Signature: hd9nmcz8f3uihmmixyaiwqngk5qwxtk6 X-Rspamd-Server: rspam01 X-HE-Tag: 1705714475-857161 X-HE-Meta: U2FsdGVkX1/9HcMIIPkZsmDahhU150p5vSJhB4PJwS7ioZocqq4MlijcV2CmoCYDsSz9+KKGr1XiM6vDkUhfN8BX/NpWkOVvgh1VXrmNftaiMJchFV5cV8kbNVsH+TO5jmlGBLtRWuhRU0jW4wi/ikXF7lewz2awxmKNYNQlzcsp6iEUUvvboIAGx2l5bZVyPXeDf/9saD/wysxb2QUsdWLFaXPF6Uq1z4UxR7AQlWAyZE9MtWvhs2gwy1PwJucA013pRr4gWwpdi1PtBpv/JFEIVQ7acxilpAz/NZhZxH7PC8DEFGaZVnUfjABQxU3BsUGH0Pdqb8tf0R90/q46RSJ5/M/zowEM8TBRBQF/TcPstOHD83rILlHqRQwsgFXCSetEBFVxGsPeIkOJVETcdV/fEw4X9ppRz4Lr139mYwFKu0yHehy9IWufg78h4IR+IKYWr2AOdkrF6/RzKKd5zAAriy8FhsLG34Wn7a2ddb4uh3DKHf69ziW1XbL2eAcWy7L+jfU98kqHBbov8yRUwQTGC08MI4T9Nxq5b4blnSVdYD4rMyk/QQrS46BrD5A0l4xCE3svMMbondihbEfU1l+fU/DQdQ3vUkvpAW95MPOsw+7YhoFv708buZ6j/BJ1vkZuuXtjotePwjx1cG4UamtpJbDkiOXb1KVf1HVZ2iqERb0Wu77QUvPBDUIiost9o6j0C6uaLeOQYUoS+ofHYbbngrhgLoRzkJtIvbV94Ln8nReohyrWr61OoE3KxfNQGwSdopeYcIP9rhJJ1P0Or6sK1DMaZC2mJNyXzqdpETy7QB3bs7yzzSKkDi6OcP952NsViVSbr41aVFZWuywz6jkmgiHlMtz50KKo5Mv9n/QeanWnTolgq6s1+gKZwB61QdI0Y36st7oH3PlG/8Hb/YPq19NnQ8U/sAWEcTu8yQWHmHNDKb2qgWkzMzRjTrh0b+prU5M4y66Dz7tgrcJ 3kChm7Mb kPCQuzo6aFlvokWAR5vRYc58U91fXn1JsMI4Rcy9kXXJEXvCBGkr998NepVb07QJBlqD49BRmujj5aDeTSutgoy0KCSlBetG8K4HDNO/+LNFgRa9YwTqp97kdklg9hi3t82FTIsHLPVtRHNNw6pHzj/8caqQp8QQcU4FEMmZb/e337cWEr4hL1kxqqmybpqz/876yuiENcnLTh2htSSmPbh6hR1+b2rgyQX34kl7WF/4+3Voz0diyK+SnjgyneT5lQhaSC+7wI6+LEbWT/XgUk3qPqSE3QMsuOPzkI6ljDX25mUe65USYYkYq41gDu3fYXzn2mIL+9wu9ai3pkNUyg1Jdbd7pchfxXAZQFB9GbyCa+tHF1dTLZyQFgw9FaA2W5oYWVObR1RX9DpPxswjT1wQ4Cw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.058944, 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 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. > 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). > > 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