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 F071AEB64DC for ; Thu, 6 Jul 2023 09:11:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79DDE8D0002; Thu, 6 Jul 2023 05:11:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74E3E8D0001; Thu, 6 Jul 2023 05:11:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 616118D0002; Thu, 6 Jul 2023 05:11:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4D8038D0001 for ; Thu, 6 Jul 2023 05:11:48 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 16E861605C2 for ; Thu, 6 Jul 2023 09:11:48 +0000 (UTC) X-FDA: 80980619496.23.9D42530 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by imf02.hostedemail.com (Postfix) with ESMTP id 8A7268000A for ; Thu, 6 Jul 2023 09:11:44 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.199 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688634704; 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; bh=XsbwGNycIeaPqi1fQd5PDBHvMt9s0d0EjXRL0hjcDNc=; b=Y+x8B2RGZS0AMM9pN9JvJpVfWdVZgKq5WAgPjBVaX1KAWZTXi19uFB5FJZjaJLLyHQ1m3k wwYzwbFh1v0fjCJ+yAtZPXWadLbKU8wB7Qy3kW98oD96UlDinwW1G6N9DAcnPv6btN4PWA 7JawTKoYipmCpSiuOYJDRtljHWvyNrc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.199 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688634704; a=rsa-sha256; cv=none; b=ydts3/oEkBTjR4APkJJjZQFWhh0bqFqAsswObYKxSvyb4jj3pq4JIZATYN+ujMPMGxHeCS ZIrEyJBgNrTyCH6STYqVDWy6fHcjLfa1MR+z56qJeMcD9IG84+CDyzG3a5YtwgFn3Z7rOW veCQHNDOYQAVQVCPdhGcy8DaJ5EjdO8= X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr X-GND-Sasl: alex@ghiti.fr Received: by mail.gandi.net (Postfix) with ESMTPSA id 237FEFF810; Thu, 6 Jul 2023 09:11:37 +0000 (UTC) Message-ID: <2084462d-b11d-7a48-3049-6bafbe81e7b4@ghiti.fr> Date: Thu, 6 Jul 2023 11:11:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [RESEND PATCH v3 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57 To: Charlie Jenkins , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: conor@kernel.org, paul.walmsley@sifive.com, palmer@rivosinc.com, aou@eecs.berkeley.edu, anup@brainfault.org, konstantin@linuxfoundation.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, mick@ics.forth.gr, jrtc27@jrtc27.com References: <20230705190002.384799-1-charlie@rivosinc.com> <20230705190002.384799-2-charlie@rivosinc.com> Content-Language: en-US From: Alexandre Ghiti In-Reply-To: <20230705190002.384799-2-charlie@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8A7268000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: a5rns5n4rkxom9g7n8e7johtr16hcnkq X-HE-Tag: 1688634704-685538 X-HE-Meta: U2FsdGVkX1+FzhDd30xTvVd2bMaicKS2P1/X0p2ZbNSg3Niub/LCSxJyPTfmoIJfB6EPXws8Z/zmXvm6PPqvroP3efnAT6rePlBMIqkqn7ongBv9KgvVlUzuslnH/JPCwOYg60VPH8Qrgs5h8Te/jY17qUf/uvY3/SvgJ+94rPGcqbY7iTYtqJv+N5Y9teN1DwmnfJfper92JqExUjtNGr8knjPm8oEakxOhuN2ME93/I5sPYJgfFezBQ0OocEEODRPi6+2reQ5iJWyHr6/vhi1zNGUU4I8Z+nc2CqgtrMoqwcvs3SOe6Fw/2pUZAZckj6X2FNtnIrdwmqce9yMnmEU5okOoAp+sJ60nZ6uuUKfTI8bcIiVk+i0i+hLSMwtZNo/NhIn2lY9LIAP/JtHaIiaGu6OBkByfjnwp/5Upq/4VjEY1KS8dzBGMmGY7+PDkHzbcnbXzA+sNmfK6+ZjN8U5B0nUW6IgCZjb/bUPvwHpjTDAzD+/XhLq3wWXaU6JKeTdaYDqrJO2CHzXdbLkviv8to9ZYmlKiuIz+I3jTm/Ux5AhF3F/IKI3/52niQNMNM5S12aL89DfwbIaVzuleu5NtO6+4ijpXRDrwXGDS/GDUMviyneSJYIumYsghF7em9urnwDDb5+8EJqFN60VOJ9Kx0zCUzdu7JiEFYcJOVxpvTUe3H6qUU3EBoxZ7gjESop3nrMwHGYQx56V5JR8GlkvdRKADc5euP9YW/Yhyd4GuiaIP10ZGnaLASGGB1gmqEggrSv/wKvDB/qBWKWqvbSbSR7F/BsWoJqAFpxGmpvubJ47Q/J3uka8Ydz7rpguO34kEjJKn4RYAzH/4mofgdyNTv+3schWWE1r/gUadNE2+V3ub6i5nCyP2mZqEAX2xCh2nq0btUuZDtkZhh2flhFeaaZeQm26nYgR+jeZiFbRXkypGw425fMQpxIpKYOdAtsDNAuMxDHYEi3pYf8g HBomnF/W 53A4gHlofljifEkYqj52eIsZM6bR8t+WnXu1+mEdZcrNNF/UMgCfXJNazV0nxbQEsTYknYMpQQmlEGckXpm1ZqZrZFf5JQ6VcKRjJ5uz4XzkhTf8HiXUOJIanVUV4H76WUbseiv6/OTeKiihTCQThOrJTIZX3hL1XCEKa 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: Hi Charlie, On 05/07/2023 20:59, Charlie Jenkins wrote: > Make sv48 the default address space for mmap as some applications > currently depend on this assumption. The RISC-V specification enforces > that bits outside of the virtual address range are not used, so > restricting the size of the default address space as such should be > temporary. What do you mean in the last sentence above? > A hint address passed to mmap will cause the largest address > space that fits entirely into the hint to be used. If the hint is less > than or equal to 1<<38, an sv39 address will be used. An exception is > that if the hint address is 0, then a sv48 address will be used.After > an address space is completely full, the next smallest address space > will be used. > > Signed-off-by: Charlie Jenkins > --- > arch/riscv/include/asm/elf.h | 2 +- > arch/riscv/include/asm/pgtable.h | 13 +++++++++++- > arch/riscv/include/asm/processor.h | 34 ++++++++++++++++++++++++------ > 3 files changed, 40 insertions(+), 9 deletions(-) > > diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h > index 30e7d2455960..1b57f13a1afd 100644 > --- a/arch/riscv/include/asm/elf.h > +++ b/arch/riscv/include/asm/elf.h > @@ -49,7 +49,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); > * the loader. We need to make sure that it is out of the way of the program > * that it will "exec", and that there is sufficient room for the brk. > */ > -#define ELF_ET_DYN_BASE ((TASK_SIZE / 3) * 2) > +#define ELF_ET_DYN_BASE ((DEFAULT_MAP_WINDOW / 3) * 2) > > #ifdef CONFIG_64BIT > #ifdef CONFIG_COMPAT > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 75970ee2bda2..752e210c7547 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -57,18 +57,29 @@ > #define MODULES_END (PFN_ALIGN((unsigned long)&_start)) > #endif > > + > /* > * Roughly size the vmemmap space to be large enough to fit enough > * struct pages to map half the virtual address space. Then > * position vmemmap directly below the VMALLOC region. > */ > #ifdef CONFIG_64BIT > +#define VA_BITS_SV39 39 > +#define VA_BITS_SV48 48 > +#define VA_BITS_SV57 57 > + > +#define VA_USER_SV39 (UL(1) << (VA_BITS_SV39 - 1)) > +#define VA_USER_SV48 (UL(1) << (VA_BITS_SV48 - 1)) > +#define VA_USER_SV57 (UL(1) << (VA_BITS_SV57 - 1)) > + > #define VA_BITS (pgtable_l5_enabled ? \ > - 57 : (pgtable_l4_enabled ? 48 : 39)) > + VA_BITS_SV57 : (pgtable_l4_enabled ? VA_BITS_SV48 : VA_BITS_SV39)) > #else > #define VA_BITS 32 > #endif > > +#define DEFAULT_VA_BITS ((VA_BITS >= VA_BITS_SV48) ? VA_BITS_SV48 : VA_BITS) Maybe rename DEFAULT_VA_BITS into MMAP_VA_BITS? Or something similar? > + > #define VMEMMAP_SHIFT \ > (VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) > #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT) > diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h > index 94a0590c6971..468a1f4b9da4 100644 > --- a/arch/riscv/include/asm/processor.h > +++ b/arch/riscv/include/asm/processor.h > @@ -12,20 +12,40 @@ > > #include > > -/* > - * This decides where the kernel will search for a free chunk of vm > - * space during mmap's. > - */ > -#define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE / 3) > - > -#define STACK_TOP TASK_SIZE > #ifdef CONFIG_64BIT > +#define DEFAULT_MAP_WINDOW (UL(1) << (DEFAULT_VA_BITS - 1)) > #define STACK_TOP_MAX TASK_SIZE_64 > + > +#define arch_get_mmap_end(addr, len, flags) \ > + ((addr) >= VA_USER_SV57 ? STACK_TOP_MAX : \ > + ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) ? \ > + VA_USER_SV48 : \ > + VA_USER_SV39) > + > +#define arch_get_mmap_base(addr, base) \ > + (((addr >= VA_USER_SV57) && (VA_BITS >= VA_BITS_SV57)) ? \ So IIUC, a user must pass a hint larger than the max address of the mode the user wants right? Shouldn't the user rather pass an address that is larger than the previous mode? I mean if the user wants a 56-bit address, he should just pass an address above 1<<47 no? > + VA_USER_SV57 - (DEFAULT_MAP_WINDOW - base) : \ > + ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) ? \ > + VA_USER_SV48 - (DEFAULT_MAP_WINDOW - base) : \ > + (addr == 0) ? \ > + base : \ > + VA_USER_SV39 - (DEFAULT_MAP_WINDOW - base)) > + Can you turn that into a function or use if/else statement? It's very hard to understand what happens there. And riscv selects ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT which means the base is at the top of the address space (minus the stack IIRC). But if rlimit_stack is set to infinity (see mmap_base() https://elixir.bootlin.com/linux/latest/source/mm/util.c#L412), mmap_base is equal to TASK_UNMAPPED_BASE. Does that work in that case? It seems like this: VA_USER_SV39 - (DEFAULT_MAP_WINDOW - base)) would be negative right? You should also add a rlimit test. > #else > +#define DEFAULT_MAP_WINDOW TASK_SIZE > #define STACK_TOP_MAX TASK_SIZE > #endif > #define STACK_ALIGN 16 > > + > +#define STACK_TOP DEFAULT_MAP_WINDOW > + > +/* > + * This decides where the kernel will search for a free chunk of vm > + * space during mmap's. > + */ > +#define TASK_UNMAPPED_BASE PAGE_ALIGN(DEFAULT_MAP_WINDOW / 3) > + > #ifndef __ASSEMBLY__ > > struct task_struct;