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.4 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,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 A8AA6C432C0 for ; Tue, 3 Dec 2019 12:58:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B5D32073C for ; Tue, 3 Dec 2019 12:58:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="o/l5+M7I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B5D32073C 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 ED00D6B050B; Tue, 3 Dec 2019 07:58:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7F706B050C; Tue, 3 Dec 2019 07:58:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1FFC6B050D; Tue, 3 Dec 2019 07:58:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id B54E36B050B for ; Tue, 3 Dec 2019 07:58:02 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 6A3F540CA for ; Tue, 3 Dec 2019 12:58:02 +0000 (UTC) X-FDA: 76223832804.17.team49_8048945e34158 X-HE-Tag: team49_8048945e34158 X-Filterd-Recvd-Size: 7883 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Dec 2019 12:58:01 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id s14so3333377wmh.4 for ; Tue, 03 Dec 2019 04:58:01 -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:content-transfer-encoding; bh=5gBysJHGfuQzzI5QYyMg+dFL1a3Os1sJupQY2cI3/tI=; b=o/l5+M7Ily1WA+L22o8YbDB5WVCgVxuiX1bHZmW15MMh7WSS89BghKM2gA9vlp2qYn z9Fhnxm1swnM7/v6mXE8m8HSC+TpvQrDYwxq37tTIccX/MGxrbUOCZrD+RjKiSLwZkjI WW2fj2EZ304zE/vIQfjI2dqJu2nJdxMo8X7XjYIPvhYZCZiANDJSvQl+vPF610qhZHuA zVgPxGahhZ3CKi7aEcrpjIUx9WrQQrnenixNNOHzlWDV/7TkdmNIl8R3a6zf0x4wM4H/ hQvoKP6FqDCl89uiQvyF5YLCK+pY/56XXoCgggxSrUr8Zsj3+Q9BRsU4qA4wq7eiUVlb OGOA== 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:content-transfer-encoding; bh=5gBysJHGfuQzzI5QYyMg+dFL1a3Os1sJupQY2cI3/tI=; b=ZXQ1drUeG488devFEmNoBWexc6ojmfWoCKPfjS/99+TwgZLiS+J94wH5eCz2NqeJLS YLqx71OOR4rZo7The21vXME4g8iX2rstsuXNLn4Z/90EQ+rtg+s2N8/+G0eKQiWZZUhB FK0mKNe3YXLOWs18WxctxLCTHPeavKLCQEfIva4repaCkul0XLJy5hjo2N+mbbErMkRW PXPYnvA+EHPUAJT5IB9+XcferANbIqJuWCj7mjYtEw9p/l23sgmG/IygkEl5qH9NOgIv 1Y6t/riOrhUKuHV6WJRTGrqoXlcXWPZmmCoIIejUxfZdskHcasdSSty/RiACA/wawVYf 5BWQ== X-Gm-Message-State: APjAAAWB8u3AvH0N/Drbuvlp5h09WyFjvrAsdABDs8LDPDfIazsGRV0a m2M+q+76T+jnBJ5Rl1qUhfFplRHBINauU46Vj3rlYg== X-Google-Smtp-Source: APXvYqyqLMU0WOMuY7vPBxyW6YZA19bg3CgXiLgb/Y0zT6wTfxKij4EJWzo0Q3cYuK2PmSc2UvUGO/onqVtCgfZdHgY= X-Received: by 2002:a1c:a98e:: with SMTP id s136mr33668714wme.140.1575377879926; Tue, 03 Dec 2019 04:57:59 -0800 (PST) MIME-Version: 1.0 References: <20191122112621.204798-1-glider@google.com> <20191122112621.204798-7-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Tue, 3 Dec 2019 13:57:48 +0100 Message-ID: Subject: Re: [PATCH RFC v3 06/36] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW To: Marco Elver , Michal Hocko Cc: Vegard Nossum , Andrew Morton , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andreas Dilger , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , David Miller , Dmitry Torokhov , Eric Biggers , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Mark Rutland , "Martin K . Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Qian Cai , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Vasily Gorbik , Wolfram Sang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: On Wed, Nov 27, 2019 at 3:48 PM Marco Elver wrote: > > On Fri, 22 Nov 2019 at 12:26, wrote: > > > > This flag is to be used by KMSAN runtime to mark that newly created > > memory pages don't need KMSAN metadata backing them. > > > > Signed-off-by: Alexander Potapenko > > To: Alexander Potapenko > > Cc: Vegard Nossum > > Cc: Andrew Morton > > Cc: Dmitry Vyukov > > Cc: linux-mm@kvack.org > > > > --- > > We can't decide what to do here: > > - do we need to conditionally define ___GFP_NO_KMSAN_SHADOW depending = on > > CONFIG_KMSAN like LOCKDEP does? > > - if KMSAN is defined, and LOCKDEP is not, do we want to "compactify" = the GFP > > bits? > > A maintainer would know the real answer, but this is my guess: making > the behaviour not change without KMSAN would probably be better. It > would require some ifdef trickery to deal with LOCKDEP on/off case > though. I actually find it quite unfortunate that LOCKDEP has this on/off case. It's already inconvenient to add a new GFP flag past ___GFP_NOLOCKDEP, as its value will be depending on this blinking LOCKDEP bit. Now imagine someone wants to add a second GFP flag that can be disabled similarly to LOCKDEP - there'll be even more hassle counting which bits are present. Michal, do you think it's possible to make __GFP_BITS_SHIFT independent from CONFIG_LOCKDEP? > > Change-Id: If5d0352fd5711ad103328e2c185eb885e826423a > > --- > > include/linux/gfp.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > index fb07b503dc45..b4e7963cd94b 100644 > > --- a/include/linux/gfp.h > > +++ b/include/linux/gfp.h > > @@ -44,6 +44,7 @@ struct vm_area_struct; > > #else > > #define ___GFP_NOLOCKDEP 0 > > #endif > > Since this change unconditionally changes GFP_BITS_SHIFT to 25, the > #ifdef for GFP_NOLOCKDEP could also go away -- but: see above. > > > +#define ___GFP_NO_KMSAN_SHADOW 0x1000000u > > /* If the above are modified, __GFP_BITS_SHIFT may need updating */ > > > > /* > > @@ -212,12 +213,13 @@ struct vm_area_struct; > > #define __GFP_NOWARN ((__force gfp_t)___GFP_NOWARN) > > #define __GFP_COMP ((__force gfp_t)___GFP_COMP) > > #define __GFP_ZERO ((__force gfp_t)___GFP_ZERO) > > +#define __GFP_NO_KMSAN_SHADOW ((__force gfp_t)___GFP_NO_KMSAN_SHADOW) > > Should this be ordered after __GFP_NOLOCKDEP with a brief comment what > it does? All of these up to __GFP_ZERO have a doc comment above. > > > /* Disable lockdep for GFP context tracking */ > > #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP) > > > > /* Room for N __GFP_FOO bits */ > > -#define __GFP_BITS_SHIFT (23 + IS_ENABLED(CONFIG_LOCKDEP)) > > +#define __GFP_BITS_SHIFT (25) > > #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1)) > > > > /** > > -- > > 2.24.0.432.g9d3f5f5b63-goog > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg