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 C7E7CEB64DA for ; Thu, 20 Jul 2023 08:14:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CE3C2800D2; Thu, 20 Jul 2023 04:14:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57EA028004C; Thu, 20 Jul 2023 04:14:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 446122800D2; Thu, 20 Jul 2023 04:14:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3526428004C for ; Thu, 20 Jul 2023 04:14:10 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E917D401DB for ; Thu, 20 Jul 2023 08:14:09 +0000 (UTC) X-FDA: 81031277418.10.7B80DC6 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf25.hostedemail.com (Postfix) with ESMTP id E2A89A0020 for ; Thu, 20 Jul 2023 08:14:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b="GDSizF/B"; dmarc=none; spf=pass (imf25.hostedemail.com: domain of alexghiti@rivosinc.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=alexghiti@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689840848; 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=pr6JMOyo8xBta00ZkqFzr6fzrP7XkXRaBSf7j7HlZ/U=; b=jTMSNllH+U/pnFMtMVazCGo5uCF8klRYi8SsKhaKPP0ezIrzAHd5Ujv3gh2g9HmMiHDNom OFYO8ADcwLdHqJiTNkKo+RWHTKg50wu67lBTZUzJov7GiGWLHF06dQHuhaqFLD0JFUz9lB L1j+Ji+XlHc42gdxAJZCCESMPc/PEmQ= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b="GDSizF/B"; dmarc=none; spf=pass (imf25.hostedemail.com: domain of alexghiti@rivosinc.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=alexghiti@rivosinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689840848; a=rsa-sha256; cv=none; b=lHICKvHXGxQ/EKt7jj9UzR9j7VspQ00F9EC/Ucj0C/nxtOk2AAjn7fqn4/Q83n9EnIpG8k DchwPbr5OPPzwOS6/rKQsABv7QyiLIW517war0B0SZsqkBz/1EF7jyhLm4V+E6PvevUQrj cG7MmA0wRcTMZY6bAxq9WMxZtEfHb1w= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-4f4b2bc1565so714032e87.2 for ; Thu, 20 Jul 2023 01:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1689840846; x=1690445646; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pr6JMOyo8xBta00ZkqFzr6fzrP7XkXRaBSf7j7HlZ/U=; b=GDSizF/B+ucio52p533XeQ4Nc4PlxzdgqFTMRTEk7FJ0ZVPf5VJ5jnJBugweo0Mv/W HXgDYWFwoJidjd0gREojTYRKn/ZUr0iAqDyxnS0Yw3vqlD/r2/mq4rZM82aa/MMeluNU on+u40mgtrds4Wt+dFZML8vAW/qGSWvn0pPwCi9Bdo0MRwJ5/Ow5Z6BDRKbxdF2oot4B O2eB0dlggRtHAdTW2jtPFmKYwSfG+oixFJoHNeHmGHTZWFzJB0Ex5rN6xES0UiAaEu9/ LRWT6ZRV9IYh9JlJE29jLMwIkkJ004O8i5TZZKVLDAspg0RPavmqbKPIw4RG8kdcXhHN JMWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689840846; x=1690445646; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pr6JMOyo8xBta00ZkqFzr6fzrP7XkXRaBSf7j7HlZ/U=; b=gPyL/HStS+8TjMwHbiDJmmmGjWK0vmmOT2ECar2VaZxcmkiTh9iYNxeGpDLtWhFS9C mHGoL5o4qb3Rf4n74t7a/EPPhR1w+wmjTvIrDtP2+UE4SmXneemZgDT/8tkhaHEbKtMz ABEv3m2t5Ifz9VNynrlwL4gA9qsZaJP1UuVHNWA5GtAkCQGmVxrLTgeuKNsUOZcYCToL 4sI8sm2gW/gLhCcr7ehTFs0pVx+WM0yXstZJAg1bBrOVfg9203KlOyN1kqmLG3ePsuMB xWJ6ofInjVhRPtxW1fagRwybXWwHIyhbNsoh8Rt00uGYr75+rkI3qBwpoiwLXgTmP1A7 SsJg== X-Gm-Message-State: ABy/qLZw298KB4n8nDcWrYr5iq18LsOfXjWQQCy8hg7jEd2ol1qJWzT2 wpgv3xXU9OsYiRInkBtyVFGEznoTsfBgEAmfUiJDuA== X-Google-Smtp-Source: APBJJlHIHnf/Ou2r9HFtGQF5G94v8undXdV+GSETq1dizsussY5NL7ytInJm0wx9i23bhmmhfP5zdP/NtqqeqgalD88= X-Received: by 2002:ac2:5b05:0:b0:4fa:6d62:9219 with SMTP id v5-20020ac25b05000000b004fa6d629219mr1495448lfn.62.1689840845696; Thu, 20 Jul 2023 01:14:05 -0700 (PDT) MIME-Version: 1.0 References: <20230714165508.94561-1-charlie@rivosinc.com> <20230714165508.94561-2-charlie@rivosinc.com> In-Reply-To: <20230714165508.94561-2-charlie@rivosinc.com> From: Alexandre Ghiti Date: Thu, 20 Jul 2023 10:13:54 +0200 Message-ID: Subject: Re: [PATCH v6 1/4] RISC-V: mm: Restrict address space for sv39,sv48,sv57 To: Charlie Jenkins 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: fjorod1zaryks61pufugzko9h6xw4xbs X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E2A89A0020 X-HE-Tag: 1689840847-250690 X-HE-Meta: U2FsdGVkX18sb8BItITYWTarI52zdl5Rxv0KRg0wjr/PP4pfuM5RMXN1XfZzveN456jRSjtHDaciN0GVSQQZoDZqK+42fk+EyolLTBU1XKJDMgY6WGOLeQXTuiygVP+H1tvcvUkwSyNQKrMRnN+YceNj3uXVNIcoNiKWWVpUwW0XOtdxOIELUboR9hCscaGeb9T44BPMNE2xmOwToptbBslv/orEB5p5SlEYUXR3roLWHZm/nOtV1Q6VSjgNDygCVqgZoa5EHnTH7BKJfG7h881Mp+yRaDWktmBNot39qiqSjQDDlSlu8dXaF/UCROsmq2IxpcCC47grnCilNvPCGlhtyTFpCSwAKIlDKeTJIYSvcwbZ43FK9a6EC3zM1OfILihva+5+k96Zv4LRDGZ3T9w1qzZ/OQNzd4wEvWPfPBqpMdS79vr5itkj/oodm9ACxBF3Jc8LH+DmRrP/I4sP1syqMtnOyO6MoG3Yy0PYRnVRtyM/nSeN9+R7PgfRc2kDH/Nf6plz91pc2SNODZ4Vi5yVuXK3RlncUAouEndaG7yjOqxpQ39LcW3NRd7R5O7bHJJU6p2sjELqEYr0PPR6+HrOsFFbg1EZ2lwK1KXDnQID+mMC87RLqhVvgj1WmAXpWbDFG0ma8tQ/yc4ixsibTNlPTyIhIImCqbpyaSjOq1SZg5HQnQGd4iPE0xUhyiHAHHDpFtn2qOn7fPZOKGKzFbo7/r+4pb5FjDzEtG6R/lyv8WDBUc1qvV8I2hkAmgo3BD7IrvyEduhziHp9V44/JbozHNw++I65ba1u4TBuMkphJf+/I2MUrEeaqFNR9mVFozzXbKgnllG8o0u3DMafNsFadtOSgVQSQSizVe47hR01FB8sBSdPJ+w3hokddaJpB5lpOrUaRIK0FBjYUEMyNrWrt/GSvmNA0a2AMuPJjqmZsPhJb7w+5V2JW1qr09bPdwvkkX4WOOeldSmBN1o XOlqOfOk +LFnZiSbHhQmjvUcc6bXOsX/IkCN5fe4gGH7rM+vw5PCtEEzNXJ/XhomeWDeemJGOcYaCvKuDnpNc4CxAsCI60KvdhuPxy7Fop9L5oaxiZgPsg5gBV4cqxDbcUQrnsTVuSWb7v5G2fiJc56+DzScPveaDoD0aRkirMuU4YTW87luAPV0scjRK8fRLm8nXpxMKTV7zU6mY/B6UXCbaQEi+P21xMancfdNE9TPPkg9F+o+Tmeuc0jajTOIF7plD8xv8riFuY4nGSApiHYb8slaxoQECIyPgAS1TlbEUPy9VLrGAedZSMu9QgMoQVb7dpeBCiSmeWOoAINg6I2P1etiL1ZyD8kBT2XlJ2geOFsU7NpQusDq4p+YiBPPWt/U0znCkbv5fPSuY+0gVDMc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000025, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jul 14, 2023 at 6:55=E2=80=AFPM 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 pr= ogram > * 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/pg= table.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_B= ITS_SV48 : VA_BITS_SV39)) > #else > #define VA_BITS 32 > #endif > > +#define MMAP_VA_BITS ((VA_BITS >=3D VA_BITS_SV48) ? VA_BITS_SV48 : VA_BI= TS) > + > #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) >=3D VA_USER_SV57) \ > + mmap_end =3D STACK_TOP_MAX; \ > + else if ((((addr) >=3D VA_USER_SV48)) && (VA_BITS >=3D VA_BITS_SV= 48)) \ > + mmap_end =3D VA_USER_SV48; \ > + else if ((addr) =3D=3D 0) \ > + mmap_end =3D DEFAULT_MAP_WINDOW; \ > + else \ > + mmap_end =3D VA_USER_SV39; \ > + mmap_end; \ > +}) What about the following instead: #define arch_get_mmap_end(addr, len, flags) \ ({ \ unsigned long mmap_end; \ if ((addr) >=3D VA_USER_SV57) \ mmap_end =3D 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 =3D 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) >=3D VA_USER_SV57) && (VA_BITS >=3D VA_BITS_SV57)) = \ > + mmap_base =3D (base) + (VA_USER_SV57 - DEFAULT_MAP_WINDOW= ); \ > + else if ((((addr) >=3D VA_USER_SV48)) && (VA_BITS >=3D VA_BITS_SV= 48)) \ > + mmap_base =3D (base) + (VA_USER_SV48 - DEFAULT_MAP_WINDOW= ); \ > + else if ((addr) =3D=3D 0) \ > + mmap_base =3D (base); \ > + else \ > + mmap_base =3D (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, we should preserve the base and I think that again, only sv57 is the corner case to deal with. > #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 >