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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9280DC4167B for ; Mon, 11 Dec 2023 14:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Kx3xiaOGjw8y6K4FbUG1wbFRP/kp8pX1HsLVA2VqgKM=; b=aE92Rp2xUIGcgP MdNpejzHaPK4DUZMKTdo5f0o8pMMpVxg5B7LEyjTCXiMqKBNzwQZxqcC0VjIviepMB3ZhdDUl62Up 9q8f+YeZE9KtA5c92S0Lan4Dj0hMKq/BSwRA441c+CeKLTQaj8PImoZvPQhxGegEcXFpObCUAtJnX XLwD+oN5GF/z6ie5dH9RVc0n9LlPR6BGKNXEvjwxIN9ntj+HGSk+xaadsdUJJ6YbBfGokPgASznkW iqM2WwtlsbEbJTrJ0aSMi/D263FrMxhnj0CvrKemKzNaNUI4BnRjRAt9kIeb0omRFBz/ywMzwlc8e utjOXf5b5oTD+XDf1mNA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rChNW-005CGp-10; Mon, 11 Dec 2023 14:35:26 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rChNM-005CFY-2e for linux-arm-kernel@lists.infradead.org; Mon, 11 Dec 2023 14:35:24 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 340F0FEC; Mon, 11 Dec 2023 06:36:02 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.34.127]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 473583F738; Mon, 11 Dec 2023 06:35:14 -0800 (PST) Date: Mon, 11 Dec 2023 14:35:11 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Catalin Marinas , Will Deacon , Marc Zyngier , Ryan Roberts , Anshuman Khandual , Kees Cook Subject: Re: [PATCH v6 08/41] arm64: vmemmap: Avoid base2 order of struct page size to dimension region Message-ID: References: <20231129111555.3594833-43-ardb@google.com> <20231129111555.3594833-51-ardb@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231129111555.3594833-51-ardb@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231211_063517_032393_52B77485 X-CRM114-Status: GOOD ( 26.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 29, 2023 at 12:16:04PM +0100, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > The placement and size of the vmemmap region in the kernel virtual > address space is currently derived from the base2 order of the size of a > struct page. This makes for nicely aligned constants with lots of > leading 0xf and trailing 0x0 digits, but given that the actual struct > pages are indexed as an ordinary array, this resulting region is > severely overdimensioned when the size of a struct page is just over a > power of 2. > > This doesn't matter today, but once we enable 52-bit virtual addressing > for 4k pages configurations, the vmemmap region may take up almost half > of the upper VA region with the current struct page upper bound at 64 > bytes. And once we enable KMSAN or other features that push the size of > a struct page over 64 bytes, we will run out of VMALLOC space entirely. > > So instead, let's derive the region size from the actual size of a > struct page, and place the entire region 1 GB from the top of the VA > space, where it still doesn't share any lower level translation table > entries with the fixmap. > > Signed-off-by: Ard Biesheuvel This is nice, and largely addresses the fear I mentioned on the earlier patches move the PCI_IO_* and FIXMAP_* regions. I'd still like to ensure that we have assertions that those don't overlap with the VMEMMAP region, but assuming those get added to the earlier patches, this looks good as-is: Acked-by: Mark Rutland Mark. > --- > arch/arm64/include/asm/memory.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 2745bed8ae5b..b49575a92afc 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -30,8 +30,8 @@ > * keep a constant PAGE_OFFSET and "fallback" to using the higher end > * of the VMEMMAP where 52-bit support is not available in hardware. > */ > -#define VMEMMAP_SHIFT (PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT) > -#define VMEMMAP_SIZE ((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT) > +#define VMEMMAP_RANGE (_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) > +#define VMEMMAP_SIZE ((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page)) > > /* > * PAGE_OFFSET - the virtual address of the start of the linear map, at the > @@ -47,8 +47,8 @@ > #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) > #define MODULES_VADDR (_PAGE_END(VA_BITS_MIN)) > #define MODULES_VSIZE (SZ_2G) > -#define VMEMMAP_START (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT))) > -#define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE) > +#define VMEMMAP_START (VMEMMAP_END - VMEMMAP_SIZE) > +#define VMEMMAP_END (-UL(SZ_1G)) > #define PCI_IO_START (VMEMMAP_END + SZ_8M) > #define PCI_IO_END (PCI_IO_START + PCI_IO_SIZE) > #define FIXADDR_TOP (-UL(SZ_8M)) > -- > 2.43.0.rc1.413.gea7ed67945-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel