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 X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A9C2C432C0 for ; Thu, 28 Nov 2019 13:30:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D0724208E4 for ; Thu, 28 Nov 2019 13:30:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="R/VzB1y+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0724208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A9CD6B052B; Thu, 28 Nov 2019 08:30:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 65B586B052C; Thu, 28 Nov 2019 08:30:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5222F6B052D; Thu, 28 Nov 2019 08:30:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 3A2016B052B for ; Thu, 28 Nov 2019 08:30:13 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id D6D9D8249980 for ; Thu, 28 Nov 2019 13:30:12 +0000 (UTC) X-FDA: 76205769864.23.bean51_7639a08bd0162 X-HE-Tag: bean51_7639a08bd0162 X-Filterd-Recvd-Size: 6392 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Nov 2019 13:30:12 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id l136so7704133oig.1 for ; Thu, 28 Nov 2019 05:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jJqOKDFjT3+a01AypCYOXpd/p74O33cPCVAoJBhsVnw=; b=R/VzB1y+iNIR1FPHNBUomauhRoQKHvZIT/HumbdjMETMs9ZrTPnTt08Ni45MeFkVT/ IE+i/zjP4QVAweHWD5/BINYJ4kyjJIFdVvu4yik9Bhi9vWDw+JruX2hCUvwt9s2EfHwN egNq9wfK5n03oDt/qz87XOQlytEnaBg93bCmbRqIE2fXu32tH9BRwZM7cJd/rTaxAEeG NLPWKE53n9AVGaQRfhrMGRArTq1mkZJQ0fjCc946ioUATgF7v/rZV7xBxIsMOpRqsMid 3LAg+CXyYDEffGgqJp/bO27ehAtNZ6VIyuGme1NbqcJmfMlTpBxIryUI8reFZ3SXT6kE nEAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jJqOKDFjT3+a01AypCYOXpd/p74O33cPCVAoJBhsVnw=; b=IBvZjUOtXCFWhK8XKOh/7GyHQysf0EMgqXRo0jHTL+eIgDovrXFeNeY9wh17MTZbMe l/1tDDTuc/v378H8n4bGRPASarPooLRTtxJu4YNvawgV+yhBiZzgTunZaFXEBV3v4mXc 7dGjYYwg6cNIOMVBh1/YvftmClMMjUtshch7PmI3HJ5Wt5LMPjY8flG6VLuPFQf4wkpv GP/PfJfC6Ccc5y/4aHFZOhOLOXYGCuKGXIDgvrxliAKTrX8ZWsFWf6JKNjRysbM+M46p x9Wm+V033znMwUUrWjDEroOXCJtMWuxes+/bIsKs68NTWLegSKQEqcdPDk0+vK4h4UCF 416A== X-Gm-Message-State: APjAAAWXevbzeRjhqWjzjGyzWe4CRHfkDOrrHDQF3V0YOYi/f0QJZL/o SxrMTVfz0Z/ZOTNcQ7ELOUIi/kywaxV17LkJh/rKTw== X-Google-Smtp-Source: APXvYqypCD6xKJL7w6Wk5FmpSR3suBx+McvtEDSDsDK1ZRpYtKYlhEj0UBoEMfqMGrEO8p/c8VJDkUKWW6X/Y6a6pok= X-Received: by 2002:aca:bf06:: with SMTP id p6mr5344526oif.121.1574947811132; Thu, 28 Nov 2019 05:30:11 -0800 (PST) MIME-Version: 1.0 References: <20191122112621.204798-1-glider@google.com> <20191122112621.204798-9-glider@google.com> In-Reply-To: <20191122112621.204798-9-glider@google.com> From: Marco Elver Date: Thu, 28 Nov 2019 14:30:00 +0100 Message-ID: Subject: Re: [PATCH RFC v3 08/36] kmsan: reduce vmalloc space To: Alexander Potapenko Cc: Vegard Nossum , Andrew Morton , Dmitry Vyukov , Linux Memory Management List , Al Viro , adilger.kernel@dilger.ca, Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , hch@infradead.org, hch@lst.de, darrick.wong@oracle.com, davem@davemloft.net, dmitry.torokhov@gmail.com, Eric Biggers , Eric Dumazet , ericvh@gmail.com, gregkh@linuxfoundation.org, harry.wentland@amd.com, herbert@gondor.apana.org.au, iii@linux.ibm.com, mingo@elte.hu, jasowang@redhat.com, axboe@kernel.dk, m.szyprowski@samsung.com, Mark Rutland , martin.petersen@oracle.com, schwidefsky@de.ibm.com, Matthew Wilcox , mst@redhat.com, Michal Simek , pmladek@suse.com, Qian Cai , Randy Dunlap , robin.murphy@arm.com, Sergey Senozhatsky , Steven Rostedt , tiwai@suse.com, tytso@mit.edu, Thomas Gleixner , gor@linux.ibm.com, wsa@the-dreams.de Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Archived-At: List-Archive: List-Post: On Fri, 22 Nov 2019 at 12:26, 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 > To: Alexander Potapenko > Cc: Vegard Nossum > Cc: Andrew Morton > Cc: Dmitry Vyukov > Cc: linux-mm@kvack.org > > --- > > Change-Id: Iaa5e8e0fc2aa66c956f937f5a1de6e5ef40d57cc > --- > arch/x86/include/asm/pgtable_64_types.h | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h > index 52e5f5f2240d..586629e20436 100644 > --- a/arch/x86/include/asm/pgtable_64_types.h > +++ b/arch/x86/include/asm/pgtable_64_types.h > @@ -139,7 +139,22 @@ extern unsigned int ptrs_per_p4d; > # define VMEMMAP_START __VMEMMAP_BASE_L4 > #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */ > > +#ifndef CONFIG_KMSAN I think it might be more readable if this was non-negative, i.e. '#ifdef CONFIG_KMSAN'. > #define VMALLOC_END (VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1) > +#else > +/* > + * In KMSAN builds vmalloc area is four times smaller, and the remaining 3/4 > + * are used to keep the metadata for virtual pages. > + */ > +#define VMALLOC_QUARTER_SIZE ((VMALLOC_SIZE_TB << 40) >> 2) > +#define VMALLOC_END (VMALLOC_START + VMALLOC_QUARTER_SIZE - 1) > +#define VMALLOC_SHADOW_OFFSET VMALLOC_QUARTER_SIZE > +#define VMALLOC_ORIGIN_OFFSET (VMALLOC_QUARTER_SIZE * 2) > +#define VMALLOC_META_END (VMALLOC_END + VMALLOC_ORIGIN_OFFSET) > +#define MODULES_SHADOW_START (VMALLOC_META_END + 1) > +#define MODULES_ORIGIN_START (MODULES_SHADOW_START + MODULES_LEN) > +#define MODULES_ORIGIN_END (MODULES_ORIGIN_START + MODULES_LEN) Are all these, except VMALLOC_END, KMSAN specific? For readability and avoid further confusion, would it make sense to prefix these with 'KMSAN_' ? This file is for x86 only -- would other architectures define these similarly? If so, maybe some of this could be moved into a helper, such as include/asm-generic/kmsan_pgtable.h? Thanks, -- Marco > +#endif > > #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) > /* The module sections ends with the start of the fixmap */ > -- > 2.24.0.432.g9d3f5f5b63-goog >