Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3482603imw; Mon, 11 Jul 2022 09:25:54 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sfdRZaUa2oZMHR1vadLF8056XqfFHcSoOKeVQjBSBuAaQ5tnDTVPjiMLBgbYxV5sSELHAO X-Received: by 2002:a17:902:9004:b0:16a:6808:e602 with SMTP id a4-20020a170902900400b0016a6808e602mr19561773plp.94.1657556754044; Mon, 11 Jul 2022 09:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657556754; cv=none; d=google.com; s=arc-20160816; b=yR3pVsi38YB+nHEEdBN5uv11+HqFraT/DH0SRwbBUL32zgC4cjvrAJz4R6bb3WAbH0 ZfffxOuu6RWWwzqkoXyuCyadP2/Y2+VWKESTVovUEonnowvUTLnD+5xlkeoSrvaJGTaD Ftc6uMyGJNIOju1cFaBku8G8+lDDqp4cgCzpoUC7X8N4hTdCtCmaHOgzoIfyw5JLcqh8 S/HADqgarzw+fz930oUo2yessi0oCXiRtQKZi5MgUG9hJVLPwqkfr58GPnbraKiyrhJJ mMTCLZQSEUF9966pdT35EyMdJR2wbK5pvDzoXURApALRTRWpx2fDw29eP605x9hUY2r+ zKxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=BOu1n0uYdCsudxoJVtyz5/UL8tUbc5xPCGC+9KrKzU4=; b=JkkWFGPCPvwmSvesoLxZT7K5ndEHwgq2C71m7KB6x8Wnz2ZHOi/ncN2dy+2EnB0ycR UqsZdMYK38NQ/KC6bXTtFybOPOz0S/glRvSWYqueRxs0DCYS+k4ozNmgFUoEBC8oG3A1 L0t5Ppx27NzIKdbl8XhveG22WfbTLC1qolJCyr5jW/wTfwimAxfsMj91r5T4xJHEWucT ed8ExtlOXebEQxNGJtsAlgKXtpDOHz2gIn+NseqnoXG2//s0tzrfxhadeANW7CcuCYGz AM88cpTOhbsNzWe6VOy90qhzdhNcU0QQhSN38H9yHwcJ3rdflEdqGx+kdx+nSsMrzIzj CKsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jfZhtAzN; 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 r4-20020a17090aad0400b001df3fb83daesi13526113pjq.157.2022.07.11.09.25.40; Mon, 11 Jul 2022 09:25:54 -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=jfZhtAzN; 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 S231860AbiGKQNo (ORCPT + 99 others); Mon, 11 Jul 2022 12:13:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231593AbiGKQNi (ORCPT ); Mon, 11 Jul 2022 12:13:38 -0400 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 810CC10BF for ; Mon, 11 Jul 2022 09:13:36 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2ef5380669cso54074757b3.9 for ; Mon, 11 Jul 2022 09:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BOu1n0uYdCsudxoJVtyz5/UL8tUbc5xPCGC+9KrKzU4=; b=jfZhtAzNU5rTNiQTs4mptKw1m2kTa9R6IQTrIM+PBmuO9yyCHXVyohDAlN7KTzn6Ah we0Ko3BSxqQWXKVCJWUqcjMFYTQ78+eNUIvCbS8SdyauGnfHltCkJdcl53p9aqKvWY3m IRJ3N9l8PXZ6ZZNwNwgBnoO6YhW3Kajtwmk3Yppwor2+/X/PfamcxKpfKaKnsiD5jMwe C7PQoBo9a8L6Gtf9tzt2aclez/bEA+frq7ccjV5CWtuVTh7ZAko/VlLMTBm4+dOZMCSz yHdAEc6RTrY4quwMSVG8R6BnUsgBhGlxx3SUpp5nDkGFTpMdMtR9QNkzjQOQ51Hqem1r ROgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BOu1n0uYdCsudxoJVtyz5/UL8tUbc5xPCGC+9KrKzU4=; b=PuVZ+S0Af3FxhT6OcZKdN1Ansg0pK2jbcf0SXw9TPSDHUl1qRtVgqfBbnHH5FiFZdu g0+l4VGftSwmZscII4dnxS/JBcpa1Z1blgXu7hJRD/YT8XDj3OICYfOQz12fGh54OdQe ej9Rz4LtWbt1lqC1R9CwqRSeiOC5REwfper6QtxJGP4dMm8XpTAqzPqOJeAqN6sz2BHM 2tFrBj1ZTOvgqo+etoTrkRCY9vWdAqVOxQDuwFSmTScg9zDPzCbsIgXtOC0WVi8AYFfd nLaF5tghooYHS/+oE5/gPCcd43tZgN3U98Zs22q3dId0hv9VTzIvS3tXR0zGI1qQZAxi hEQw== X-Gm-Message-State: AJIora+c/9sTCvdqJZy9bdgefKpJ6h61HiYI+DBEpLCDudWuja6Kg+kU edb5w3pF7C01vWsh6zgxluJrGBq9PZ9Zgl21EQKixQ== X-Received: by 2002:a81:98d:0:b0:31c:921c:9783 with SMTP id 135-20020a81098d000000b0031c921c9783mr19996386ywj.316.1657556015569; Mon, 11 Jul 2022 09:13:35 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-10-glider@google.com> In-Reply-To: <20220701142310.2188015-10-glider@google.com> From: Marco Elver Date: Mon, 11 Jul 2022 18:12:59 +0200 Message-ID: Subject: Re: [PATCH v4 09/45] x86: kmsan: pgtable: reduce vmalloc space To: Alexander Potapenko Cc: Alexander Viro , Alexei Starovoitov , 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 , 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=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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 On Fri, 1 Jul 2022 at 16:23, Alexander Potapenko wrote: > > 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 70e360a2e5fb7..ad6ded5b1dedf 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) Comment what VMEMORY_END is? (Seems obvious, but less guessing is better here.) > +#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 39c5246964a91..5806331172361 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.37.0.rc0.161.g10f37bed90-goog >