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 8DB29C61DF4 for ; Fri, 24 Nov 2023 10:21: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=redvmOFStJpH8SJ+XRx+tMhtWl1PvUCUhqfgquxxEJA=; b=2vPQPu8/FNSo253VCapvswWjL3 5A3fpAnfYjBkm07KIDLhau7OHuJYfQ+zPMhqiZWXGYNcdfUmbC6jt6WRgiaQEHcr3eEFUDv/JO4sM CfQcaskw5LuOFKAvwAWc1au1C+b/oRp7ic5nYGzUO6TV/d9Zp6xDvEGTIZ43op6PjTXRj1Xym5IAx tYdNLgZTqREXSWKjEN+3Z/ak6ZFLO5UIEBE8jCvMwjTxIQqXAKAk3hxpe9AYSLQRbpyFYYxxOKNUX Oa/iup11dQ+4xI0nKLDXqzWDtMJSljg6gNQHLk2aZg5d2s53Uhrz7kaJ3fmdD7kjtd6PAOT+yWhH+ p9QRfl8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r6TIl-006ogU-0I; Fri, 24 Nov 2023 10:20:47 +0000 Received: from mail-wm1-x349.google.com ([2a00:1450:4864:20::349]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r6TIX-006oZf-1b for linux-arm-kernel@lists.infradead.org; Fri, 24 Nov 2023 10:20:34 +0000 Received: by mail-wm1-x349.google.com with SMTP id 5b1f17b1804b1-408695c377dso9358495e9.2 for ; Fri, 24 Nov 2023 02:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700821231; x=1701426031; 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=V86olf1EKJaGQIDLZDyTyPOGst5YdmjimBytLucyYgQ=; b=1d+suDUtmr/YWzgHRXaAQM0WLTclzP2MrdZWW24pcdU34p7bTe76ckPmfUcZ+yrlBU KGSIIyFtF3yoNJiGFcPCVnxNqpfMKExiRo+AT1Ds4Ry7Pp3zT0yzhqjZ5j2CCI2Ira1C rOQNoJRoc6p7krhNOxpgIAReaPwukqa7iRzRkLg4Unxa6pyvYSvTZy5vh2ksYxhCaMJx dLC94heYWdp+Orf2jWurCuFANKUIDWsXoDVpFdMLo+agLorm1AL5+3S6Yx81+sGVGpMR B54j1OQKcqWj6yD5naNeMj28vJLOo4CyTQd6DPjqjL4afXi0SIcikI9ww6HBkrQFXQef E24A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700821231; x=1701426031; 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=V86olf1EKJaGQIDLZDyTyPOGst5YdmjimBytLucyYgQ=; b=DrpSc5L/hPcdbu3XjZEXqWRhnz8pHdnOcAY3obRbSnWWZ8WrjQSGCfqSLOLtSA6Twt 809wCtxWNOyL3eu0LJFmed3tWjmOy7EvqHQIxul+vBuArshODRf0orgs9yFSevgTIgTj cOJcPDFNKuDbSkBrO5nWGmrmHhT/NidNVYPRUA6H+amDmdgI60+FKbYbALMY9wDZcV3F Z5VNdAsyQOJxgmaOeM6q3bYDA5CJwQurtpdFiAkbwlNMy6KluiALTTSC9oNXpH0W0RYq fhG9rTXGvfJOot+CNLof9Ve0EoB5A0gmC4zonJQ02DlWIZw8UVNsL2u5/SViEjuWTQZq 7BgQ== X-Gm-Message-State: AOJu0YyzhENePZHa96ln5KwbNExygj4x2kjlLT6qE2xmruYp4lvq65T3 4rlS8oQcOs1V7Td1lXbvlSu61xy86qqKJw/MOFsMKWKTSws134stiSFZKLJCbIN4r//kdyHDKv+ 4/kYXrCkqzyTumX5RZa9hARBsok28iq6pbNCqjeCanGlJJGdSNTLUP+86iH11ci51JsMM7CY1Tn U= X-Google-Smtp-Source: AGHT+IEv0Jf3vHaRCycMnBj5VeR2nnJQKH9V6EYuLNmnaVoxelKGumyrc8C1NGPQ35rU7hR2Vwwlx8le X-Received: from palermo.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:118a]) (user=ardb job=sendgmr) by 2002:a05:600c:4e4b:b0:409:6edc:8a07 with SMTP id e11-20020a05600c4e4b00b004096edc8a07mr44734wmq.4.1700821231718; Fri, 24 Nov 2023 02:20:31 -0800 (PST) Date: Fri, 24 Nov 2023 11:18:48 +0100 In-Reply-To: <20231124101840.944737-41-ardb@google.com> Mime-Version: 1.0 References: <20231124101840.944737-41-ardb@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=2460; i=ardb@kernel.org; h=from:subject; bh=wwOsRm3FZFgGJ9li8cLLVrn99cMWNOQlYRvDxthbRTc=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JITWhonORgn5Unf+zP/m2Qsd0H3BM7HP/sTJOMUZ2ke/hy v8FNXEdpSwMYhwMsmKKLAKz/77beXqiVK3zLFmYOaxMIEMYuDgF4CJijAyvPzwL8WplrLm1ef+S b+0cv/9dDda4k3DP0JN9a+Qct7w6hv8xC58GHIkxZJ2Qusf4lYGI3VHWh1GMi6L22ccv97x3iZs dAA== X-Mailer: git-send-email 2.43.0.rc1.413.gea7ed67945-goog Message-ID: <20231124101840.944737-49-ardb@google.com> Subject: [PATCH v5 08/39] 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-20231124_022033_532797_80317742 X-CRM114-Status: GOOD ( 16.82 ) 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. 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 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