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 72355C47DDB for ; Tue, 23 Jan 2024 14:55:15 +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:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=Ux5FEuSCInVXsv/7DieWf/EFj04GKwnvbIIgnHa30sI=; b=kDHYeNosRHYdMAlTVyRT8cUNqZ cP9pc0z1uMHlPXR6kbrMVMAyotKNvblvyIldsXyDWe3fci0Y0qd3+/Vu3xmZETYny4e+5qFVdHlIx 6RUvKB99onh0HgO/mIKaOnPD8VCPTn15ygCFNVZPGNIRTtheCsEVEpDhBHcYPfI4p2wUX7q/LYxqK pOax0aaeLPx1EmuHYYbtyD88eEYTRxcOxlWQH4H1xjmCcFSY0U6aP6apCE8GxM1qQO2BgXAW2tcfd aMDkwpNZOTS4WvgdfId38UOsBO6KVFXRwXRjHNsI9ofOn98kxpjM/ErTdj84GCcCCmFiHom7KLzWi nbvr/Hdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rSIAs-00GtkP-1c; Tue, 23 Jan 2024 14:54:50 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rSIAc-00Gtci-1R for linux-arm-kernel@lists.infradead.org; Tue, 23 Jan 2024 14:54:35 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-dc221fad8c7so6311940276.3 for ; Tue, 23 Jan 2024 06:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706021673; x=1706626473; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jA+DKoZHst8Q9IMSbPhxUf/d1q0YMDko04eruQNM4yk=; b=pFPQeQpEVWKWoAXUuI1KW2fhxrIovUKTbY50hOetwkxYLNZddS7GHebm5XNMLGjBD2 mT7YfyewwSlVvfNU5Q7TIm1MIBhVm1W3ZvFPfMY4G8OW+WtdBMglmFmHaPl587QQgV9e p3wTwoa2PVUyeXAYf4OVDE8Q6RoEb4ylZhvo2NQ9CsJh1eLW8VzeZS1zicTV3MW19uPH u0/StuQz1mByT0QMeG1GIYe4HNijmn1tqb5L2R0rvaNqmnUMY1echSOC+5M7G4T9vtZ5 ZtJszQ1+3uyzjvW+fjgoK+PCK9ffnhwSKIPNdFraaVRBtWxPdsi1SkurA8/OU6auatgP 8Gnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706021673; x=1706626473; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jA+DKoZHst8Q9IMSbPhxUf/d1q0YMDko04eruQNM4yk=; b=VVPFhJP7gKIeNZlBvLghxLRJSwVpC/H/qs/KIoWWPLWcv1SzAKknvAZVa0HXgSor36 ZH8bV/9swTjAaNmzTaIYmjpwEbaQrnQBdTAIclVDHIij3Hb2zaZDRkLax8K6dtG62ZKz +s+WIV7UE8lUp6YTtzwfbt4E2DXRPhutbiGRvr8sXt55kAJpkGxZzrKl1yPDw9xLDjL9 8hHErA0zUpM/2NBnG/QF2H4rmMYop5wKyJShUo7M0J4f3KV+xalxdl9Y6uIOEZdkaRn1 L3xYmdPLmyrCNOOXEQ48hZn8q5lBlLrmSQ9yPmrzAEW8oUHzPdOuTlFGmdKdUGHdCP+6 ZPbw== X-Gm-Message-State: AOJu0YzIZu72+IgUsPOEGcqbePwhYUt7fn2GUUgx+k+xN1h9rgbPzoPJ F9MhCgho3vA2y/GKHeywjvzyZ32evmUzW9j1vz3nEo5uJXrb+ju3XugH1AIKsB0KZJzydsOg7Gk GvzMy8Bak1asrHuKB4YNzs9dVPfBnreQn3yDoF009z3xMZ/XH326vQ9GkOHNeNVyHlWB9hzZTNK 29Cn/vwPwAYFz+mZAxQb2KH4CwIJZTuG+we0oYgZBW X-Google-Smtp-Source: AGHT+IECY0+JYPv7S/1IlpDt42Vxp0vrygBO4p6W3UbYe1m/cIW5GDmRTwR983UrSByQn61uha0Wid3r X-Received: from palermo.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:118a]) (user=ardb job=sendgmr) by 2002:a05:6902:1005:b0:dc2:5525:f6b with SMTP id w5-20020a056902100500b00dc255250f6bmr2741798ybt.7.1706021673082; Tue, 23 Jan 2024 06:54:33 -0800 (PST) Date: Tue, 23 Jan 2024 15:53:04 +0100 In-Reply-To: <20240123145258.1462979-52-ardb+git@google.com> Mime-Version: 1.0 References: <20240123145258.1462979-52-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=2503; i=ardb@kernel.org; h=from:subject; bh=yh9XctYC8E98u+//lXEWXJdFuG3EvzjK+wj6zwGC/yg=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIXX9pQsG+5NSdv+8eF7/Z2C6yu7+jc+qdsWnZDk1vi+cc rrY3Gt6RykLgxgHg6yYIovA7L/vdp6eKFXrPEsWZg4rE8gQBi5OAZiIci8jw4nN+nMWdPxfMXH3 zpxTvEsjJt6+vdhO9PRnLda5ZlNrzfcy/LNOFpZe/Ec1YRtnrO7BuZVb5wjJbtLcHSnxtGTNveW Fe7gA X-Mailer: git-send-email 2.43.0.429.g432eaa2c6b-goog Message-ID: <20240123145258.1462979-57-ardb+git@google.com> Subject: [PATCH v7 05/50] arm64: vmemmap: Avoid base2 order of struct page size to dimension region From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org Cc: Ard Biesheuvel , Catalin Marinas , Will Deacon , Marc Zyngier , Mark Rutland , Ryan Roberts , Anshuman Khandual , Kees Cook X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240123_065434_497825_B5FA4748 X-CRM114-Status: GOOD ( 17.07 ) 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 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. Acked-by: Mark Rutland Signed-off-by: Ard Biesheuvel --- 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 f3be3ea74138..60904a6c4b42 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.429.g432eaa2c6b-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel