From patchwork Tue Mar 7 14:04:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 65528 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2450297wrd; Tue, 7 Mar 2023 06:09:51 -0800 (PST) X-Google-Smtp-Source: AK7set/lLYVs/wtF0XGVrWL18nGERTpwNx8g3R9dBn5nBp9xqaIDcWWh4EDG4YA62HUYZWzG77EX X-Received: by 2002:a17:90b:4a47:b0:22b:eb46:7d2 with SMTP id lb7-20020a17090b4a4700b0022beb4607d2mr15630165pjb.47.1678198190834; Tue, 07 Mar 2023 06:09:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678198190; cv=none; d=google.com; s=arc-20160816; b=WGAx0ZspLz2nZ6R2cSQXRnjy9CQaDF0TGDU4AQRH1mYf7pcApHje5+/w6oNp89YaGI Vm+R0Ds6IzIVCBx5o7N0I2d29+irNUPLRxu2DTglRVSiMRzUayczfnip55IPOYoRyh5j j9tNaJY8qK35eIvibpWPmKq/KjH/N27gRbkJfG77CYICwesCmVv4mrC/OsSO+gOBDctk ZrlIk0GF6IH8b1YIkToHaSrhMONyXnJrKKzOZyV3RLfG+cNI9atxlWAlPLHlQxKL/Ems mBEvtYj/7y+BOn3y5CoJGj26gzQRpp3G5GI1dDn+FttZmKNovgV7tGFMm9cP+x1CAoBv sRiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ThvzJxZPZWZ8QxiVP6wP4QznmNTfe1SgGpfULjc7QTM=; b=OMKN/W8aBKWs22HVz/M+hvSMTYsjsB/zmI2u1OAjvH8hgZ7MsewD1vE4N5cyzvgY6w /+dNHf1si6EbSN+ELhNGGFg4my77l0fhzJ2Dr9CdQAuycObK2z+/chvW3gidr7UaxCqO 6pitq3JBFmqC6YjAdqwsWEdmEuDlxx6d4ixh/TSqG5y/ToxqBwhHYIN2j1sS8Z26+yTQ Kbx5AVkxSPey+vivbcIV7l7csSZBhKl/p4CwbYqk9tczm4q9DPax0CJbgbqa4cRYeSDJ rb9vaP7qzn/hxFTgNzZY/tFXuUPdMC/X0xA0f4H1Rk87RJGhIN7Z+x1L71Qx4wJjnos5 p8JQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="St+QY/Uy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 14-20020a630e4e000000b0050017d1b7c6si10141142pgo.767.2023.03.07.06.09.36; Tue, 07 Mar 2023 06:09:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="St+QY/Uy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230034AbjCGOHp (ORCPT + 99 others); Tue, 7 Mar 2023 09:07:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbjCGOHV (ORCPT ); Tue, 7 Mar 2023 09:07:21 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82CD685B10 for ; Tue, 7 Mar 2023 06:06:58 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 20C8861453 for ; Tue, 7 Mar 2023 14:06:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91483C433EF; Tue, 7 Mar 2023 14:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678198017; bh=ywYQ7UcqIIS79iv7ntjeEpAqcLnJP0A5n4rXQJWafZ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=St+QY/UycgrASh5ECehIA8iTtJ4dKOYbVOY8uHJHxUSm0HuG6ndhv3ZJB7fsQV+0p LkCvojMp+3BBJYeZ3ZTWnlM8G7OH/D2zkJ1idMJ8xQfGv13xtMOX4qpCuLux4Ux3Ul PZ0iNYxHSrXuEuLVHalp6ew5iV3EtAI80dxE2YlOVYGiGN50Up6PO+JUcdTOfL+hfW GX8wbMhaO6Hm2x8J1XoO2iLqf9YksC5kpb4cBtQsYxACwegWde/3bpSzwXAr0l2zhV 1HMf/ffHCOrxY7CnNRxBl8dYg6jfIo0ChjdZMy20bTMEHZn/SwFkapn3VgCyQL2CKQ WhzpvnnTXRpaQ== From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Catalin Marinas , Will Deacon , Marc Zyngier , Mark Rutland , Ryan Roberts , Anshuman Khandual , Kees Cook Subject: [PATCH v3 08/60] arm64: vmemmap: Avoid base2 order of struct page size to dimension region Date: Tue, 7 Mar 2023 15:04:30 +0100 Message-Id: <20230307140522.2311461-9-ardb@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230307140522.2311461-1-ardb@kernel.org> References: <20230307140522.2311461-1-ardb@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2467; i=ardb@kernel.org; h=from:subject; bh=ywYQ7UcqIIS79iv7ntjeEpAqcLnJP0A5n4rXQJWafZ8=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIYXdhS/0ZUuZrrTL9d0HdLbuj/IRLz0876vtuZwymSN+S 9okv0h3lLIwiHEwyIopsgjM/vtu5+mJUrXOs2Rh5rAygQxh4OIUgIk02DEyPBBp8Z6/++iHaIH6 315yubsVruxxDveqPRlwZ53THYEZrgz/zCcxnrzfd5+/t0PMUrmpedXJDcuTVPcZanz/wC+36NB JTgA= X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759718346372743951?= X-GMAIL-MSGID: =?utf-8?q?1759718346372743951?= 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 9b9e52d823beccc6..830740ff79bab902 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_128M) -#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 (ULONG_MAX - SZ_1G + 1) #define PCI_IO_START (VMEMMAP_END + SZ_8M) #define PCI_IO_END (PCI_IO_START + PCI_IO_SIZE) #define FIXADDR_TOP (ULONG_MAX - SZ_8M + 1)