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 F3CA4C001DE for ; Mon, 7 Aug 2023 21:12:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65F996B0074; Mon, 7 Aug 2023 17:12:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60FE58D0003; Mon, 7 Aug 2023 17:12:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B1058D0001; Mon, 7 Aug 2023 17:12:21 -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 3DAFE6B0074 for ; Mon, 7 Aug 2023 17:12:21 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0F907B215C for ; Mon, 7 Aug 2023 21:12:21 +0000 (UTC) X-FDA: 81098556882.27.25C33AF Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf14.hostedemail.com (Postfix) with ESMTP id 134CC100003 for ; Mon, 7 Aug 2023 21:12:18 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=fOuezLgQ; spf=pass (imf14.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.171 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=1691442739; 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=LLabNF1oUru8G8E0mb8z07qDe8jY0hmn23BXjQmIFo0=; b=xKTuvzVOGB5/vWr8f9saE5MWSMF4yVGPkphyqwGwDzVb17ABR6uUE8Sn2V4Bg+3yBhzcAc uGze5r57zAX4n75scPuHdf3RhE0b35uGToofMWHqKK/2N4+F7OU3L+rVVz3FKvsexpMRHW XDveSqFIURxst3ULONhMmBqXcpWubwQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=fOuezLgQ; spf=pass (imf14.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691442739; a=rsa-sha256; cv=none; b=BNuTd4i6eo+eESd+bgcpICMpEAUxetLBKzN3YYzVS1pjciUTvINmPyjvCJbNzxJn6Eb2nH T5O/kTtSJKUWZKi+wFm0fnwEmnWHFtGCc9HnZWh5Hl5wFZl2wNppRD+fLHL/O38k5JTj5C qwKQEKFRpS3uQeHy3wQFqfzpJGMTC28= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1bbc87ded50so32970025ad.1 for ; Mon, 07 Aug 2023 14:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1691442737; x=1692047537; 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=LLabNF1oUru8G8E0mb8z07qDe8jY0hmn23BXjQmIFo0=; b=fOuezLgQNJfG941ygz4q5rwJTaSzKWKWRgTe8pPAw2H3M/CXJiyfFwfHQMQra0JJB7 6AqwM8/wSw/bttG9JFm/DHUaNEKteNe7XDbEpfoDSPcviuXsvK+jyVLm5CF3keLnc3rh SrGRmeyuoLDkFRE7oDrpq6R/vjZd44xbXoGm63bXdGOtkgMkSz4EW9bOrVIKAUptiWEZ PHJEQEe9e39mD6PtBqiOkI8kx8MVj3ee9N3gvEyuTcrOpOrfRBuQJFSdFvAWPPxiLgaw P2o5cbtfNyYixv9K6m6YCWi4quYH5qQ34J4ofvKo6JEprZXei9vNbfiUPebeskAAQBCC sgjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691442737; x=1692047537; 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=LLabNF1oUru8G8E0mb8z07qDe8jY0hmn23BXjQmIFo0=; b=G/n+gI08/CBKjs5JcWsUWDNBhFonxiYpgzPYDLcyixipe98+hdCjDBKID26NHoC91P 4T3mWvkoGy/Eb8Y+DIK+WlReaUoI4tqkmeCEtslKCcZRasj8Bp+ZBj8xuOq5NUN+cI7H z5R9/nWI/2WnztamldzVbgv5DyC0+L6PgyMNMIi7BTRyDlc6r681rKFyvnaoDM2pfXJd oPQ5uvlEztRAzzvbAN6PbnPyodRDDPyinQiGsGKN4Qy+MGtfiz/R4O1owWtljYa08JV5 LwJf9o8zthGjPtoQ0K9BYL5TmSBGJId7yGHSKcszuydwEAYkdjv3IaXYIcnrY7Vyyz8k Q5Iw== X-Gm-Message-State: AOJu0Yz2+qqbIoVOM4uhYciRtTfaBoDmvGdxW4v6aQJmxaZVVNArXjHm oRZoLVPVMzZ2YhteIRqvvyy/sw== X-Google-Smtp-Source: AGHT+IEPKHYE/TxBZ7l9uiuErBP4gHqfE60SXyNlo1aBqM49wt1t/o4eZRyv8IC1K50OY1wr6aSjXA== X-Received: by 2002:a17:903:22cb:b0:1bb:d045:ae8 with SMTP id y11-20020a17090322cb00b001bbd0450ae8mr11946777plg.7.1691442737567; Mon, 07 Aug 2023 14:12:17 -0700 (PDT) Received: from ghost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id f12-20020a170902ce8c00b001bb97e51ad5sm7350677plg.99.2023.08.07.14.12.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 14:12:16 -0700 (PDT) Date: Mon, 7 Aug 2023 14:12:14 -0700 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, alexghiti@rivosinc.com Subject: Re: [PATCH v8 1/4] RISC-V: mm: Restrict address space for sv39,sv48,sv57 Message-ID: References: <20230727212647.4182407-1-charlie@rivosinc.com> <20230727212647.4182407-2-charlie@rivosinc.com> <4c692993-86ab-fdce-8c78-f676cf90e861@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c692993-86ab-fdce-8c78-f676cf90e861@ghiti.fr> X-Rspamd-Queue-Id: 134CC100003 X-Rspam-User: X-Stat-Signature: 9ra3195x93rptykhd4yrejgwb4cfu7u1 X-Rspamd-Server: rspam01 X-HE-Tag: 1691442738-141582 X-HE-Meta: U2FsdGVkX1+BKArjkkTDF5htcw4218T4hFbDZJHaTZORBKCVSpDYso37AHMHcxAypVKYIITeErT28V5E/zhdnRIG3222OeHtuZCFKjEBPyZvGpR1K3REfSrcI+fB9igZT4vJupwxto+ESmsspvz4coMQgwiYI8mzmlq6gZbJ6UEQ6Tbw2mpeHSkEaP20P9ofygdnV3R5dmiQzfrlSBz878BfCVHmKItNObPrt5AJEMme7vXnlyg0tI7JZlGlCB+RREYg1ROn80FhPI8oHVxx51Ql9ivffhpQSx0s2q4KYkJQAcfYQkyZaPDZeF84vk2783PEEkIioL+HTJQjTOmfJYvrnILo2iWdebNHXQKi8EF7nnw8oz+wuE4TPRV+6LZzSaWniu2b54Vu1AHplL/AhHUQ0SZnJitm7/BUbdgL1lfISoGQL1I09WfZAfbJiZ08iS17Rxwjs8RTU0prcZp/3cPuKXiE3/dy/OWPOlwFjo0xhfR2J0wcjru/ACHOrRQXIPa7PYJoAZqVKSFbqI2LyE8XMaBUMwWwmgmw2ojVF2y2UCwIvO3ywO28UtwFjvs9OTm8BkQU1i/bC1R6WHMkYxN6YZnhV0eRbRY3ZhKGZ9luKmGPoUkLq5AbaqbrsHTM50KkXGZ3T+gChI0i9HD/tnp38enIbKJykVZpXmJYkDhP0n131xe6o7OWbSMvImlTWOg8YkQQEWxgbMDXcqlMDMEUO3z3dd8HaQsx2PHSuL2AyHIUZF2Dd6hKUJvaADY+O52dpWl6rnYWpaZxsn65s7ejAuREQ6CJ003liDHcB2Ox9ochHjLudkSZQ1JWC5MkwaCFGFzWjQkNh6W4/46mq3rZ/LSETRGHO9NaXsTxBLWAWZ5qUPX1n+CnxHL7PFs4/ZB+8N7OEQQMu84z48lPQ2Izl1WF8uZuzElHgwsOt06bCSlHRnSFgJSeb9J2P5kqbFGIEYPyJTDCAJklFGL RE4rChXr 9uchz2szZFzStJJabDEkFX6gf7RznKNY7Vx3R4HVOsrIRq+dJ49wGMWabYHdxTs1WaWPpBBXFpOc+sR66yr39QNOLyYfIYfWMmdvnpVAZC+y4hqkAD6fUzKuDDPOtGPVBllnJEZx1EdRr2A5qBSJaxzXoyPWYLZrFcIcjMgm0AIBnDt5YMpTWfQ3dmzCEKWRc2UjOr7rn+2gAITM9UR3h9a4JWAzVdLexbx6DY68o3QkdaD0KC3GTXeHxlArarGt9LQIMIrTLQQHZvBuXGHi2RJr/hbIS6dEbahQi2D7M66rvPqMJs6kxEK2Kwr0sduAq7M/nC1L5bAw2sjCOe0ZuoZPYGcWMfC7BSKNtT/IW7qEeQ/48jLYFXMcyJEPhTUXLxpfkLTm0KtrdFjyc2d7QCaXy/bX6rfh8vIbbkyU3GjRButKahCtmo6gbCo4YImTviq3iM+Os62oBhuA= 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 Sun, Aug 06, 2023 at 11:53:51AM +0200, Alexandre Ghiti wrote: > > On 27/07/2023 23:26, 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 | 20 +++++++++++- > > arch/riscv/include/asm/processor.h | 52 ++++++++++++++++++++++++++---- > > 3 files changed, 66 insertions(+), 8 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..c76a1ef094a4 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -63,8 +63,26 @@ > > * 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)) > > + > > +#ifdef CONFIG_COMPAT > > +#define MMAP_VA_BITS_64 ((VA_BITS >= VA_BITS_SV48) ? VA_BITS_SV48 : VA_BITS) > > +#define MMAP_MIN_VA_BITS_64 ((VA_BITS >= VA_BITS_SV39) ? VA_BITS_SV39 : VA_BITS) > > > Here the condition is always true right? > Yes, that condition is always true, I can eliminate the conditional. > > > +#define MMAP_VA_BITS (test_thread_flag(TIF_32BIT) ? 32 : MMAP_VA_BITS_64) > > +#define MMAP_MIN_VA_BITS (test_thread_flag(TIF_32BIT) ? 32 : MMAP_MIN_VA_BITS_64) > > > I think you should use is_compat_task() here instead of > test_thread_flag(TIF_32BIT). And what about introducing VA_BITS_SV32 instead > of hardcoding 32? > Sounds good. > > > +#else > > +#define MMAP_VA_BITS ((VA_BITS >= VA_BITS_SV48) ? VA_BITS_SV48 : VA_BITS) > > +#define MMAP_MIN_VA_BITS ((VA_BITS >= VA_BITS_SV39) ? VA_BITS_SV39 : VA_BITS) > > > Ditto here. > > > > +#endif > > #else > > #define VA_BITS 32 > > #endif > > diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h > > index c950a8d9edef..e810244ea951 100644 > > --- a/arch/riscv/include/asm/processor.h > > +++ b/arch/riscv/include/asm/processor.h > > @@ -13,19 +13,59 @@ > > #include > > +#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; \ > > + typeof(addr) _addr = (addr); \ > > + if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && test_thread_flag(TIF_32BIT))) \ > > + mmap_end = DEFAULT_MAP_WINDOW; \ > > > Wouldn't that prevent a sv57 system to allocate sv57 addresses when sv48 is > full unless explicitly asked? > Yes that is a good point, that should be STACK_TOP_MAX as well. > > > + else 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 \ > > + mmap_end = VA_USER_SV39; \ > > + mmap_end; \ > > +}) > > + > > +#define arch_get_mmap_base(addr, base) \ > > +({ \ > > + unsigned long mmap_base; \ > > + typeof(addr) _addr = (addr); \ > > + typeof(base) _base = (base); \ > > + unsigned long rnd_gap = (_base) - DEFAULT_MAP_WINDOW; \ > > + if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && test_thread_flag(TIF_32BIT))) \ > > + mmap_base = (_base); \ > > + else if (((_addr) >= VA_USER_SV57) && (VA_BITS >= VA_BITS_SV57)) \ > > + mmap_base = VA_USER_SV57 + rnd_gap; \ > > > Shouldn't it be mmap_base = VA_USER_SV57 - rnd_gap? > No, rnd_gap is a negative number here. 'base' is equal to DEFAULT_MAP_WINDOW - gap - rnd. It does seem more clear if it is a positive number so I will set rnd_gap to DEFAULT_MAP_WINDOW - (_base). > > > + else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ > > + mmap_base = VA_USER_SV48 + rnd_gap; \ > > + else \ > > + mmap_base = VA_USER_SV39 + rnd_gap; \ > > + mmap_base; \ > > +}) > > + > > +#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(TASK_SIZE / 3) > > - > > -#define STACK_TOP TASK_SIZE > > #ifdef CONFIG_64BIT > > -#define STACK_TOP_MAX TASK_SIZE_64 > > +#define TASK_UNMAPPED_BASE PAGE_ALIGN((UL(1) << MMAP_MIN_VA_BITS) / 3) > > #else > > -#define STACK_TOP_MAX TASK_SIZE > > +#define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE / 3) > > #endif > > -#define STACK_ALIGN 16 > > #ifndef __ASSEMBLY__