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 4E8D5C0015E for ; Wed, 26 Jul 2023 14:04:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 949168D0001; Wed, 26 Jul 2023 10:04:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D1ED6B0072; Wed, 26 Jul 2023 10:04:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7734E8D0001; Wed, 26 Jul 2023 10:04:54 -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 61B386B0071 for ; Wed, 26 Jul 2023 10:04:54 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1B4AF160F81 for ; Wed, 26 Jul 2023 14:04:54 +0000 (UTC) X-FDA: 81053934108.02.E83AEAF Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf09.hostedemail.com (Postfix) with ESMTP id 179DC140241 for ; Wed, 26 Jul 2023 14:02:36 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=v9O3J2Ew; dmarc=none; spf=pass (imf09.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=charlie@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690380157; 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=i3qDaq0f1OxJhpdvpNf87CWRe2a484dJSynLBrocNRs=; b=GGDTvIL0do/6C3eBK1Nn8DR/hFJURBxQfJuAHgtmH36b/DEoZugUvbCEYLWCvf98H6zTEV WG7JD1gmc9susSdvRaR8VUobF0QuPTU5Ke0fv7gyrFmLEfc9r6SlXrfc72meguz5r4kfEF MapzUPAaVHW61edl4z4kS+V6WPBgwjw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=v9O3J2Ew; dmarc=none; spf=pass (imf09.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=charlie@rivosinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690380157; a=rsa-sha256; cv=none; b=WUCsOa3K4SbpMrI85SBBY2UOusAQaGS+9SsEGBmD1wwC5l1SwFdAREjLPMvpQReZToHAQ/ 3gqBLrNSVPGQpULacjEoAnipzMCw7ZP3cjlUGhHvs26J0KlUyk6lPag+GypnReCvdUsao1 CWybNkXhLk8U6G1ebAJQXcjZp6/eirs= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1bb81809ca8so35616835ad.3 for ; Wed, 26 Jul 2023 07:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1690380155; x=1690984955; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=i3qDaq0f1OxJhpdvpNf87CWRe2a484dJSynLBrocNRs=; b=v9O3J2EwmJ+bAwI34M0dzmx7i0AsS29WdmP/9LE1CdEVJ8m1qfm14OJX5SSBCeLnQQ dPk9Zubn6upXSBumweY4mVEtluOVWG9lRFgHRx12/ogmZJq+ZwKeyxPCQwlVudnF5Y3y 2Dg/FqDNkBDq97zHSLMmeeC9u3NGuTbLshMKNapnWFb4mKNij6cqIZjBP7WzA2Fs51fk CkxmaErozUkm1H8CBAiVxfGprXEyoQINhvdbsGktKKP9h8Eid/rXZqiW/GHpJO7WA3s3 +tIYtIszl6AXy2+DynKpo1+FbXpAuH3DeKluj2kNQzbwn9/Hvk2gjhVCsnrrrKoOdW4/ GZ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690380155; x=1690984955; h=in-reply-to:content-transfer-encoding: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=i3qDaq0f1OxJhpdvpNf87CWRe2a484dJSynLBrocNRs=; b=KcgmrH4fP8oHirmlcjBMUN8TD8fZKV2lQy/gZyV0BfxcVC3g4jnJkrgW36Sgld6Y8m j46UIRY5SnfHhDF/qZetpg3wK3fVHB93dgGnwi7V1cESWf13+Tptese/2ViCVyA6sIK/ hV3fWDMf3j9jsONj4/pdYKJt/TYtWmaa/xef9kLHZ6W+bUVE0npEvGsS+4suGPPyEFYX ZJbTO0CUlLk4mfNbk2uaHveSJteEMq+nohCSVgqwE8YTVnHpC93Hi3QF9fCR5ELmZOi6 q4pd8FWIJjF9QBZT2l5jT5vNQNMmCOm+DxEHfT7AbIKh3k5xRcgunNABlbGMuYL7Is1K m9TQ== X-Gm-Message-State: ABy/qLb+owS6+I12+uBgICO9dTvzElPwqMo5DFLjUCICorzqoZmymV0h MaJP8Lk9a78vO8NA/DZmcflAuQ== X-Google-Smtp-Source: APBJJlG7wpvZUVtencQnkDUvyX2MWDqoaSaKUNXQr4fuZuTOSlKZomZWUoQiFIu8sdXB60c9lDmo5Q== X-Received: by 2002:a17:902:e885:b0:1b5:5052:5af7 with SMTP id w5-20020a170902e88500b001b550525af7mr2705823plg.8.1690380154815; Wed, 26 Jul 2023 07:02:34 -0700 (PDT) Received: from ghost ([2601:c0:ca7f:e7c0:14ff:979a:dd27:29d7]) by smtp.gmail.com with ESMTPSA id jw11-20020a170903278b00b001b89d9a58e9sm5832564plb.132.2023.07.26.07.02.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jul 2023 07:02:34 -0700 (PDT) Date: Wed, 26 Jul 2023 10:02:30 -0400 From: Charlie Jenkins To: Alexandre Ghiti Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, 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, rdunlap@infradead.org Subject: Re: [PATCH v6 1/4] RISC-V: mm: Restrict address space for sv39,sv48,sv57 Message-ID: References: <20230714165508.94561-1-charlie@rivosinc.com> <20230714165508.94561-2-charlie@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 179DC140241 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: iqnrpb4j7n7mcssqzu6yhpdqdnbb1ffc X-HE-Tag: 1690380156-396891 X-HE-Meta: U2FsdGVkX1+BgCppP8w8Msi9Q0sU3hxrVwYNcp8K8fD4upQqzdlFFe0sgxdzjAcyg3SRCureb9R1vTmyRxs8abV1RbOlRz+/UAH7m/JsYPI0LwewsWI5oVUhY3Al9WzsSzPd26cZbRPhOLWpOvnv12uwbteeNaVMitM6ZRh3PJNxMcwvFaXHSkcBg5VJNqHkF8w9Y5PTdgPz5aDV41Uer0EYZsz+nRXlBTLA7cIBQ6hOTk0Blwsq91yJE0yPaNV8IJI8iA8IZl16fmGFKa5AVkkxK4K9SPPj3DZu0hxP0QFwoxO7ADaHSirde1BTpXWKbcYPXyC56dF01Nr+1hbRrM1UCQy84fjTv4hkGmmFyQGCfchyH8vEOA6YSqxH7qJv4nH/TguY7DxwZ2CIePAxIJiyGZBx1Pb6Yo79bHzwcT606y5X9mTC24aNWnVaI59vsJ7FAA+iidjt+cVd13YBR1JRb0o01tugfU9U5CfgthnMQIma3kHI4UEGOy7CNdSlrgC++a1OXX2DBPpk1F7Is8nOK+Hfd1jsI4ypm3X8MHtXcZhCfG3Fjdp2dKoCUHCjW+vzLjFd+bZE7l8HVi992MCtNNJY/ZmjMpkwjnaBPdNKar4PgwPz6dJcPIyOScPUBEBbZefaKG7Y83Jbbk3aAJGWAS7ZrY7d4+Q0KXXiFiH/UXwXvqun5iVK3kYe7oxKB2D/fnx53Wk27ZRwhaUXb44xXuogZa3N9tqaH9QIN8o5Y8OAMgylU0RE7DBCEUsn/j08N9b3n4SMZpDI9qLNivS5Lln+J7/sWKnc5S6T0O/Dqpm/dstvcSb4oXTvu+yVCwCgZJx0cqVP+VQ84lAOLRAb4ICirq4p1uTahfy1Mn3HN0mqYWn1bvDwBJqvy1dFlO82zAjAqtcqZYWFP2SIgfzhvnuOJwIGrqUQ/QYVx+xxmHJj1oMbzUrC2EXIVR6QSJJ1yk2sDrU+FohwtHb ptTzd/Lx ucz3DXzT3DdzhmImmIxGO39A+Ck/3bROvcwP9+6I4NkzbcSIuQgn2MwXdY+dFyJ0YIVrTXmapzAFUrgh/pSFV76/zhFQZBokVm/l3Pt8zR+7NoqK8y5WlbPByDfI4zzLkQ7DshsbVfYddWPGOsBpdutoLH+F40XYoOlQ4QmtP/utWX2f+/SGYIZALkoAix1FKSXgBfmjAyrc3QF6tdMPcmqzCHvw5yRzN7Fx2K3mDLrG2a3eSAkxhxO7dVzCds8CLbM7LqpaK0k58MxQ5rhH/3zteOE437oeC/UQwRKNuwHkeOngFhpQ3g2yDi7sbdNPojltW9hNLoxKFVuAsrjTaMn7hxil2IyWidtF55VNBiWQ1hHPtsEi5n3YlC27KpQgZUNLhkMy9Cl0EFH4fMcSiqfbsv9xpvhHuqke6mHhevkACqrmcw8oY4JJSddy5ZsZvD1IBX0jT/9UY0XlKWsf4bVwVUtBvIgXKv/Q/PA/vzrIOh9/A0j3meSYksiq1bV18MH8pKxKGCC3+hLhMoFpEWnybA6g/US65oyFgAyb0qBqtMxji2T8LH6GBtFK2ChKZHglW 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: On Thu, Jul 20, 2023 at 10:13:54AM +0200, Alexandre Ghiti wrote: > On Fri, Jul 14, 2023 at 6:55 PM Charlie Jenkins wrote: > > > > Make sv48 the default address space for mmap as some applications > > currently depend on this assumption. 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 | 12 +++++++- > > arch/riscv/include/asm/processor.h | 46 +++++++++++++++++++++++++----- > > 3 files changed, 51 insertions(+), 9 deletions(-) > > > > diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h > > index c24280774caf..5d3368d5585c 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..e13f5872bfe9 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -63,12 +63,22 @@ > > * 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 MMAP_VA_BITS ((VA_BITS >= VA_BITS_SV48) ? VA_BITS_SV48 : VA_BITS) > > + > > #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 c950a8d9edef..14a5396eed3d 100644 > > --- a/arch/riscv/include/asm/processor.h > > +++ b/arch/riscv/include/asm/processor.h > > @@ -13,20 +13,52 @@ > > > > #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) << (MMAP_VA_BITS - 1)) > > #define STACK_TOP_MAX TASK_SIZE_64 > > + > > +#define arch_get_mmap_end(addr, len, flags) \ > > +({ \ > > + unsigned long mmap_end; \ > > + if ((addr) >= VA_USER_SV57) \ > > + mmap_end = STACK_TOP_MAX; \ > > + else if ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ > > + mmap_end = VA_USER_SV48; \ > > + else if ((addr) == 0) \ > > + mmap_end = DEFAULT_MAP_WINDOW; \ > > + else \ > > + mmap_end = VA_USER_SV39; \ > > + mmap_end; \ > > +}) > > What about the following instead: > > #define arch_get_mmap_end(addr, len, flags) \ > ({ \ > unsigned long mmap_end; \ > if ((addr) >= VA_USER_SV57) \ > mmap_end = STACK_TOP_MAX; \ // Maybe a comment here that > says it returns the max user address of the current mode, not obvious > at first sight. > else \ > mmap_end = DEFAULT_MAP_WINDOW; \ > mmap_end; \ > }) > > The only corner case is when sv57 is active, then only a hint greater > than VA_USER_SV57 can return a sv57 user address. Otherwise, we just > need to return the default mmap end right? > > > + > > +#define arch_get_mmap_base(addr, base) \ > > +({ \ > > + unsigned long mmap_base; \ > > + if (((addr) >= VA_USER_SV57) && (VA_BITS >= VA_BITS_SV57)) \ > > + mmap_base = (base) + (VA_USER_SV57 - DEFAULT_MAP_WINDOW); \ > > + else if ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ > > + mmap_base = (base) + (VA_USER_SV48 - DEFAULT_MAP_WINDOW); \ > > + else if ((addr) == 0) \ > > + mmap_base = (base); \ > > + else \ > > + mmap_base = (base) + (VA_USER_SV39 - DEFAULT_MAP_WINDOW); \ > > + mmap_base; \ > > +}) > > + > > From arch_pick_mmap_layout() > (https://elixir.bootlin.com/linux/latest/source/mm/util.c#L433), the > "base" argument is: > > - either STACK_TOP in top-down (more or less some random offset) > - or TASK_UNMAPPED_BASE in bottom-up (more or less some random offset) > > When bottom-up is the current mode, we should not change the base, so > adding (VA_USER_SV57 - DEFAULT_MAP_WINDOW) in the first case is not > right for me. When sv48 or sv57 are the active mode, > DEFAULT_MAP_WINDOW is equal to VA_USER_SV48 right? So (VA_USER_SV48 - > DEFAULT_MAP_WINDOW) is 0, so not useful. And for the last case, when > the user asks for a sv39 address whereas the active mode is sv48 or > sv57, then (VA_USER_SV39 - DEFAULT_MAP_WINDOW) is negative and the > base is smaller which is not correct. > In the bottom-up case mm->mmap_base is directly used instead of arch_get_mmap_base so base will not be modified in that case. The math here is confusing so I can refactor it. I like your suggestion to extract out the rnd value of base with (base) - DEFAULT_MAP_WINDOW since base is defined as PAGE_ALIGN(STACK_TOP - gap - rnd) and STACK_TOP is DEFAULT_MAP_WINDOW. This (-gap-rnd) value can then directly be used instead of redoing the math in each if. > In the bottom-up case, we should preserve the base and I think that > again, only sv57 is the corner case to deal with. > > For both this comment and the one above, I think we should allow the user to default back to sv38. I talked to Palmer and he would prefer allowing selection of sv38. Since there is no overhead, there is no need to prevent the user from doing so. > > #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; > > -- > > 2.41.0 > >