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

From: Michal Hocko <mhocko@kernel.org>
To: Alexander Potapenko <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 Memory Management List <linux-mm@kvack.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Andy Lutomirski <luto@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	David Miller <davem@davemloft.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Eric Biggers <ebiggers@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Harry Wentland <harry.wentland@amd.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ilya Leoshkevich <iii@linux.ibm.com>, Ingo Molnar <mingo@elte.hu>,
	Jason Wang <jasowang@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Rutland <mark.rutland@arm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Michal Simek <monstr@monstr.eu>, Petr Mladek <pmladek@suse.com>,
	Qian Cai <cai@lca.pw>, Randy Dunlap <rdunlap@infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Takashi Iwai <tiwai@suse.com>, Theodore Ts'o <tytso@mit.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW
Date: Wed, 25 Mar 2020 19:38:32 +0100	[thread overview]
Message-ID: <20200325183832.GI19542@dhcp22.suse.cz> (raw)
In-Reply-To: <CAG_fn=XFusumWfja438Db9SshQnojBAoQH_vzuZ5ZsSORyGREQ@mail.gmail.com>

On Wed 25-03-20 18:40:29, Alexander Potapenko wrote:
> On Wed, Mar 25, 2020 at 6:26 PM Alexander Potapenko <glider@google.com> wrote:
> >
> > On Wed, Mar 25, 2020 at 5:19 PM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > 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.
> >
> > Great idea, will do!
> > Guess PF_ flags isn't a scarce resource?
> 
> Actually, no, we are out of bits in current->flags already.
> I could introduce a separate flag into struct task, but that won't
> work in interrupt contexts - how do you solve that problem for FS/IO
> allocations?

NOFS/NOIO is not a problem for IRQ context because we never do reclaim
from that context.

I was also not aware that there are users from the IRQ context. I
thought this would be an internal KMSAN stuff. What would be the IRQ
context you call this from?

Anyway, if you cannot go with the task_struct then a per-cpu value
should work, right?

-- 
Michal Hocko
SUSE Labs