Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4129909ioa; Tue, 26 Apr 2022 18:11:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydKPbzmzHP7Qd8oYOTU9hchECG4TFYddbl9POtMCImqEXL9HL2UL6ySa9FFRxEr5cOnvt8 X-Received: by 2002:a17:902:a417:b0:158:ed2c:3740 with SMTP id p23-20020a170902a41700b00158ed2c3740mr25919562plq.121.1651021889262; Tue, 26 Apr 2022 18:11:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651021889; cv=none; d=google.com; s=arc-20160816; b=oYK9PL956RNA4e72FTqSEh+FNiu9y+qgSZWzUAnIcXyk32f9B860ujfJ4Gah1ndCev vymA4xQHbtLKCO6ETWowgSVnSuFf+6m3qX9JZuy0xQSosQqXIbsP3uyh7534Po/dRzh2 ND/ARkJznB/H3tY/fOjJ+35So23k2C2HXXl+1eY2cRh6KU/8vx40ZuRQTFcz09qUybRv HCY5Ca5UDqlVN+9A9IEXJRBGkCm9i+k/haw1JAelNt03T8RcKZ/HeGy/K3Zi03X9EPn0 L0vOCiyPMWcylcWs1US0mlyWBtVvVDqnzlAPAfDgmmBOGd7bJAlVA9dxrTaAiIacuTg3 EfRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=H2XcU3OLx+0JTyyML32bzgUT5MJiV2tDmnYI11nI1dE=; b=JcOJ0FvEdw2JKDOuycolqY7yJ8M2IPG2opzJ9BL4QiHWJLubbzMRf4uSEqQ1uBm6zK MdQsJ+HivYSc+mjvm6Z/5ChdINeciGsh6uQjX6t9sDcljYZ/TpKvRFJzGGw9s21HpEi0 Akx9NEuUkD8isGJBtrnk0QouAobe8RhU6Y1HGMvd9kLQKJcGyH1fzCxsebCNCdf7ObrF G+uryPnl43Jhe2u/UscREmURJ6uau+vwwr1QqLKFeg2VJ8swuDvt53HjYiKq+hFJWCLQ yGgTvjx/cYL5kZsMnNBe0jALbzwES/blIgpK/Hl867r61F8c1zZc2ZABX/ObM8HjP6cn oEpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="m/GoUZBV"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f65-20020a636a44000000b00399149a5d14si39811pgc.205.2022.04.26.18.11.12; Tue, 26 Apr 2022 18:11:29 -0700 (PDT) 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=@google.com header.s=20210112 header.b="m/GoUZBV"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353203AbiDZQsj (ORCPT + 99 others); Tue, 26 Apr 2022 12:48:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353180AbiDZQs1 (ORCPT ); Tue, 26 Apr 2022 12:48:27 -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 B49EC191C63 for ; Tue, 26 Apr 2022 09:44:47 -0700 (PDT) Received: by mail-ej1-x64a.google.com with SMTP id go12-20020a1709070d8c00b006f009400732so9165457ejc.1 for ; Tue, 26 Apr 2022 09:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=H2XcU3OLx+0JTyyML32bzgUT5MJiV2tDmnYI11nI1dE=; b=m/GoUZBVtlZMRq+FF0SH5aCHlTGSvaapuxEDbVMKlEUnlusQPCCZ7ebjbcCdUrWYb5 a8Bnd3p86A4nE5NEzf9NbCXsFTEls9lTknebhOvAE06AdOtYHsT4/XF7t90n+nJ5iebk sRGdLEAOOW9bUwdhOZndjscgKwN1eOVOb9hwxXJ7DP2x/BYwqNzZ6yzf2ohW5qzq+FEZ g3mr3p0uqiTWn5KToQ7MIQy5yDLS3i1YymgzGDrCkkGyLo8f/tQJWjvGzdC5snsMrVUx RKkkljd+V3QJEWhwnCDg+P32Vbl+YhkiLRuywjeqifPG0/ok+r70FeWu7XYIUm7eYfDk 3sOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=H2XcU3OLx+0JTyyML32bzgUT5MJiV2tDmnYI11nI1dE=; b=NNFBuUQrZ+kAATzJtYPjMdyG2wmR87LbrBcRAwEPK4CXdg7Q3jQYHO8Fx/fYepV8pj gyIrWLKtjUNpmj1lpyc4JZkEmiKG1gzalAbA3/scqcpm2TkkG8Fg3UGIsR5lfa7ik3XF pceBtoXvWvUq4zX5BaDcRcg7zJzvCgU4vNZi+fGsQdR3q+fR2RYF2Rx3Ucxfj0YVU7F6 GeKpAq2eRTTojdGuA6TBg9q9+WWvQYfH3FnH1hDcVt1dLCIsUJ824Cj77CBtVHmt22eS RuTvdyvkCB/CdjnJb/sCTa5No3sBoDNLuHXsrM5YSn56r0P//+7Qbdvfy4dSoILPclwy jnqw== X-Gm-Message-State: AOAM532HFAf4aCst3QHhKUJBRuoH+IOruOXr7XAxJOkjeYG7XiopCJO9 cVS74CsP5w4hFzhR8TyVgge0ElUMua0= X-Received: from glider.muc.corp.google.com ([2a00:79e0:15:13:d580:abeb:bf6d:5726]) (user=glider job=sendgmr) by 2002:a05:6402:4315:b0:426:155:e4a3 with SMTP id m21-20020a056402431500b004260155e4a3mr1554638edc.324.1650991485934; Tue, 26 Apr 2022 09:44:45 -0700 (PDT) Date: Tue, 26 Apr 2022 18:42:39 +0200 In-Reply-To: <20220426164315.625149-1-glider@google.com> Message-Id: <20220426164315.625149-11-glider@google.com> Mime-Version: 1.0 References: <20220426164315.625149-1-glider@google.com> X-Mailer: git-send-email 2.36.0.rc2.479.g8af0fa9b8e-goog Subject: [PATCH v3 10/46] x86: kmsan: pgtable: reduce vmalloc space From: Alexander Potapenko To: glider@google.com Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , 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 , 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 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 Link: https://linux-review.googlesource.com/id/I9d8b7f0a88a639f1263bc693cbd5c136626f7efd --- arch/x86/include/asm/pgtable_64_types.h | 41 ++++++++++++++++++++++++- arch/x86/mm/init_64.c | 2 +- 2 files changed, 41 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h index 91ac106545703..7f15d43754a34 100644 --- a/arch/x86/include/asm/pgtable_64_types.h +++ b/arch/x86/include/asm/pgtable_64_types.h @@ -139,7 +139,46 @@ extern unsigned int ptrs_per_p4d; # define VMEMMAP_START __VMEMMAP_BASE_L4 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */ -#define VMALLOC_END (VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1) +#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 shadow + * 3rd quarter: KMSAN_VMALLOC_ORIGIN_START to + * VMALLOC_END+KMSAN_VMALLOC_ORIGIN_OFFSET - vmalloc area origins + * 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 modules. + */ +#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 offsets + * 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_OFFSET) +#define KMSAN_VMALLOC_ORIGIN_START (VMALLOC_START + KMSAN_VMALLOC_ORIGIN_OFFSET) + +/* + * 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_OFFSET + 1) +#define KMSAN_MODULES_ORIGIN_START (KMSAN_MODULES_SHADOW_START + MODULES_LEN) +#endif /* CONFIG_KMSAN */ #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 96d34ebb20a9e..fcea37beb3911 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; - for (addr = VMALLOC_START; addr <= VMALLOC_END; addr = ALIGN(addr + 1, PGDIR_SIZE)) { + for (addr = VMALLOC_START; addr <= VMEMORY_END; addr = ALIGN(addr + 1, PGDIR_SIZE)) { pgd_t *pgd = pgd_offset_k(addr); p4d_t *p4d; pud_t *pud; -- 2.36.0.rc2.479.g8af0fa9b8e-goog