From nobody Fri Dec 19 19:00:13 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35BC8C6FA8A for ; Thu, 15 Sep 2022 15:06:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230354AbiIOPGb (ORCPT ); Thu, 15 Sep 2022 11:06:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230392AbiIOPFr (ORCPT ); Thu, 15 Sep 2022 11:05:47 -0400 Received: from mail-ej1-x64a.google.com (mail-ej1-x64a.google.com [IPv6:2a00:1450:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC82760517 for ; Thu, 15 Sep 2022 08:05:04 -0700 (PDT) Received: by mail-ej1-x64a.google.com with SMTP id hp18-20020a1709073e1200b0078054727517so1233935ejc.0 for ; Thu, 15 Sep 2022 08:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date; bh=PTsTfo/gJDV7iQzWmhln0w3yo3kBxDNSc9M3IZOTBoE=; b=JPgXbB5IFWEFHgGxJgBDcBqsn7OA+OOmod3TkAJCtmEW3tmDIEAaPKco4V3rSfeVUT GdXM8f5AP9MppFWIxBTCdhy9ugH7naOnesHXUn34A53RkPodiqw3X1l45i+8mKggb98k Rfas/CBCSU/l2+KKyy5Yy+k2HFZReEtFK6RUw8luzU4yWnpDATvBrwpXvH5uKPEFz/CY fMEUsRqiEpjIjSm6svk+PcgL/IEq9k1aaJenW+l4RBh8IWYn4eFeXv42PrPIL6LXSCM+ D6Wc5KgbtUAixY99TEj/8stcJrQCa9sE6zMp90t6pz7+Avl4xRSk9+TMfjnHy6he5k4v 4d0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date; bh=PTsTfo/gJDV7iQzWmhln0w3yo3kBxDNSc9M3IZOTBoE=; b=C00kBuZsQP0SNHzEnL3SfGvo8rzR7bpM/rWGh2EU+hSvY/hcihT+zi3n1/7BHr58D0 Rv7ao3w08efrZ/t6O9YoaoGzz6llV5w/aurFJ5ONEle8jXfMPfokpbZ5AIppllUyIldo BBJ0V5LOByqblKRjRzkR7rXLXlVIOfjSyEKoCfSjabenqOrzWproLI8cMb3DmnlRrro0 FwZSemngCcAI3IgBFrlp2hhaQDJvY5TkWhgDtfxx3H4qe4ARv6hCo0IXceikKqZqE8pm 8fXIiU6EvHLf+b0mHkfVbyqfhBwfKG4yOSxRVvubpNxEqaOW9XOfa4CxafD9L7nL0TdT DkXQ== X-Gm-Message-State: ACrzQf0MZvaR3dK5AgaJrtQx/C/6BK+4BUsIr9CDam9ccYkMD4ho2Z6X MrbDZOaNQs1TvPnoktfLQQSG+zh9aEc= X-Google-Smtp-Source: AMsMyM4p6KqskMugQKLr3d2QoJoMFJ9ItcCVTDioHI8BQ0089p953E4XlBHrGmtCk9sUiS5VpTwgREGXwKI= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:686d:27b5:495:85b7]) (user=glider job=sendgmr) by 2002:a17:907:2cce:b0:77a:6958:5aaa with SMTP id hg14-20020a1709072cce00b0077a69585aaamr280253ejc.245.1663254303074; Thu, 15 Sep 2022 08:05:03 -0700 (PDT) Date: Thu, 15 Sep 2022 17:03:43 +0200 In-Reply-To: <20220915150417.722975-1-glider@google.com> Mime-Version: 1.0 References: <20220915150417.722975-1-glider@google.com> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220915150417.722975-10-glider@google.com> Subject: [PATCH v7 09/43] x86: kmsan: pgtable: reduce vmalloc space From: Alexander Potapenko To: glider@google.com Cc: Alexander Viro , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Biggers , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Stephen Rothwell , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" KMSAN is going to use 3/4 of existing vmalloc space to hold the metadata, therefore we lower VMALLOC_END to make sure vmalloc() doesn't allocate past the first 1/4. Signed-off-by: Alexander Potapenko --- v2: -- added x86: to the title v5: -- add comment for VMEMORY_END Link: https://linux-review.googlesource.com/id/I9d8b7f0a88a639f1263bc693cbd= 5c136626f7efd --- arch/x86/include/asm/pgtable_64_types.h | 47 ++++++++++++++++++++++++- arch/x86/mm/init_64.c | 2 +- 2 files changed, 47 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm= /pgtable_64_types.h index 70e360a2e5fb7..04f36063ad546 100644 --- a/arch/x86/include/asm/pgtable_64_types.h +++ b/arch/x86/include/asm/pgtable_64_types.h @@ -139,7 +139,52 @@ extern unsigned int ptrs_per_p4d; # define VMEMMAP_START __VMEMMAP_BASE_L4 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */ =20 -#define VMALLOC_END (VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1) +/* + * End of the region for which vmalloc page tables are pre-allocated. + * For non-KMSAN builds, this is the same as VMALLOC_END. + * For KMSAN builds, VMALLOC_START..VMEMORY_END is 4 times bigger than + * VMALLOC_START..VMALLOC_END (see below). + */ +#define VMEMORY_END (VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1) + +#ifndef CONFIG_KMSAN +#define VMALLOC_END VMEMORY_END +#else +/* + * In KMSAN builds vmalloc area is four times smaller, and the remaining 3= /4 + * are used to keep the metadata for virtual pages. The memory formerly + * belonging to vmalloc area is now laid out as follows: + * + * 1st quarter: VMALLOC_START to VMALLOC_END - new vmalloc area + * 2nd quarter: KMSAN_VMALLOC_SHADOW_START to + * VMALLOC_END+KMSAN_VMALLOC_SHADOW_OFFSET - vmalloc area sha= dow + * 3rd quarter: KMSAN_VMALLOC_ORIGIN_START to + * VMALLOC_END+KMSAN_VMALLOC_ORIGIN_OFFSET - vmalloc area ori= gins + * 4th quarter: KMSAN_MODULES_SHADOW_START to KMSAN_MODULES_ORIGIN_START + * - shadow for modules, + * KMSAN_MODULES_ORIGIN_START to + * KMSAN_MODULES_ORIGIN_START + MODULES_LEN - origins for mod= ules. + */ +#define VMALLOC_QUARTER_SIZE ((VMALLOC_SIZE_TB << 40) >> 2) +#define VMALLOC_END (VMALLOC_START + VMALLOC_QUARTER_SIZE - 1) + +/* + * vmalloc metadata addresses are calculated by adding shadow/origin offse= ts + * to vmalloc address. + */ +#define KMSAN_VMALLOC_SHADOW_OFFSET VMALLOC_QUARTER_SIZE +#define KMSAN_VMALLOC_ORIGIN_OFFSET (VMALLOC_QUARTER_SIZE << 1) + +#define KMSAN_VMALLOC_SHADOW_START (VMALLOC_START + KMSAN_VMALLOC_SHADOW_O= FFSET) +#define KMSAN_VMALLOC_ORIGIN_START (VMALLOC_START + KMSAN_VMALLOC_ORIGIN_O= FFSET) + +/* + * The shadow/origin for modules are placed one by one in the last 1/4 of + * vmalloc space. + */ +#define KMSAN_MODULES_SHADOW_START (VMALLOC_END + KMSAN_VMALLOC_ORIGIN_OFF= SET + 1) +#define KMSAN_MODULES_ORIGIN_START (KMSAN_MODULES_SHADOW_START + MODULES_L= EN) +#endif /* CONFIG_KMSAN */ =20 #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) /* The module sections ends with the start of the fixmap */ diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 0fe690ebc269b..39b6bfcaa0ed4 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -1287,7 +1287,7 @@ static void __init preallocate_vmalloc_pages(void) unsigned long addr; const char *lvl; =20 - for (addr =3D VMALLOC_START; addr <=3D VMALLOC_END; addr =3D ALIGN(addr += 1, PGDIR_SIZE)) { + for (addr =3D VMALLOC_START; addr <=3D VMEMORY_END; addr =3D ALIGN(addr += 1, PGDIR_SIZE)) { pgd_t *pgd =3D pgd_offset_k(addr); p4d_t *p4d; pud_t *pud; --=20 2.37.2.789.g6183377224-goog