Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW

From: Michal Hocko <mhocko@kernel.org>
To: glider@google.com
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Marco Elver <elver@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	linux-mm@kvack.org, viro@zeniv.linux.org.uk,
	adilger.kernel@dilger.ca, aryabinin@virtuozzo.com,
	luto@kernel.org, ard.biesheuvel@linaro.org, arnd@arndb.de,
	hch@infradead.org, hch@lst.de, darrick.wong@oracle.com,
	davem@davemloft.net, dmitry.torokhov@gmail.com,
	ebiggers@google.com, edumazet@google.com, 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@arm.com, martin.petersen@oracle.com,
	schwidefsky@de.ibm.com, willy@infradead.org, mst@redhat.com,
	monstr@monstr.eu, pmladek@suse.com, cai@lca.pw,
	rdunlap@infradead.org, robin.murphy@arm.com,
	sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
	tiwai@suse.com, tytso@mit.edu, tglx@linutronix.de,
	gor@linux.ibm.com, wsa@the-dreams.de
Subject: Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW
Date: Wed, 25 Mar 2020 17:19:52 +0100	[thread overview]
Message-ID: <20200325161952.GF19542@dhcp22.suse.cz> (raw)
In-Reply-To: <20200325161249.55095-4-glider@google.com>

On Wed 25-03-20 17:12:14, glider@google.com wrote:
> This flag is to be used by KMSAN runtime to mark that newly created
> memory pages don't need KMSAN metadata backing them.

I really dislike an idea of the gfp flag. If you need some form of
exclusion for kmsan allocations then follow the pattern of memalloc_no{fs,io}_{save,restore}
History tells us that single usecase gfp flags are too tempting to abuse
and using incorrectly.

> Signed-off-by: Alexander Potapenko <glider@google.com>
> To: Alexander Potapenko <glider@google.com>
> Cc: Vegard Nossum <vegard.nossum@oracle.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Marco Elver <elver@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> 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?
> 
> 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 be2754841369e..e1ab42b5e9ce2 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
> +#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)
>  
>  /* 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.25.1.696.g5e7596f4ac-goog
> 

-- 
Michal Hocko
SUSE Labs