All of lore.kernel.org
 help / color / mirror / Atom feed
From: glider@google.com
To: Vegard Nossum <vegard.nossum@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Michal Hocko <mhocko@suse.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Marco Elver <elver@google.com>,
	 Andrey Konovalov <andreyknvl@google.com>,
	linux-mm@kvack.org
Cc: glider@google.com, 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: [PATCH RFC v4 06/42] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW
Date: Fri, 20 Dec 2019 19:49:19 +0100	[thread overview]
Message-ID: <20191220184955.223741-7-glider@google.com> (raw)
In-Reply-To: <20191220184955.223741-1-glider@google.com>

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 <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 e5b817cb86e7..30f8d3ed9bde 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.24.1.735.g03f4e72817-goog



  parent reply	other threads:[~2019-12-20 18:50 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 18:49 [PATCH RFC v4 00/42] Add KernelMemorySanitizer infrastructure glider
2019-12-20 18:49 ` [PATCH RFC v4 01/42] stackdepot: check depot_index before accessing the stack slab glider
2019-12-20 18:49 ` [PATCH RFC v4 02/42] stackdepot: build with -fno-builtin glider
2020-01-03 17:37   ` Steven Rostedt
2019-12-20 18:49 ` [PATCH RFC v4 03/42] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c glider
2019-12-20 18:49 ` [PATCH RFC v4 04/42] stackdepot: reserve 5 extra bits in depot_stack_handle_t glider
2019-12-20 18:49 ` [PATCH RFC v4 05/42] kmsan: add ReST documentation glider
2019-12-20 18:49 ` glider [this message]
2019-12-20 18:49 ` [PATCH RFC v4 07/42] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ glider
2019-12-20 18:49 ` [PATCH RFC v4 08/42] kmsan: reduce vmalloc space glider
2019-12-20 18:49 ` [PATCH RFC v4 09/42] kmsan: add KMSAN runtime core glider
2019-12-20 18:49 ` [PATCH RFC v4 10/42] kmsan: KMSAN compiler API implementation glider
2019-12-20 18:49 ` [PATCH RFC v4 11/42] kmsan: add KMSAN hooks for kernel subsystems glider
2019-12-20 18:49 ` [PATCH RFC v4 12/42] kmsan: stackdepot: don't allocate KMSAN metadata for stackdepot glider
2019-12-20 18:49 ` [PATCH RFC v4 13/42] kmsan: define READ_ONCE_NOCHECK() glider
2019-12-20 18:49 ` [PATCH RFC v4 14/42] kmsan: make READ_ONCE_TASK_STACK() return initialized values glider
2019-12-20 18:49 ` [PATCH RFC v4 15/42] kmsan: x86: sync metadata pages on page fault glider
2019-12-20 18:49 ` [PATCH RFC v4 16/42] kmsan: add tests for KMSAN glider
2019-12-20 18:49 ` [PATCH RFC v4 17/42] crypto: kmsan: disable accelerated configs under KMSAN glider
2019-12-20 19:44   ` Eric Biggers
2020-01-09 14:56     ` Alexander Potapenko
2019-12-20 18:49 ` [PATCH RFC v4 18/42] kmsan: x86: disable UNWINDER_ORC " glider
2019-12-20 18:49 ` [PATCH RFC v4 19/42] kmsan: x86/asm: softirq: add KMSAN IRQ entry hooks glider
2019-12-23 19:58   ` kbuild test robot
2019-12-24 14:38   ` kbuild test robot
2019-12-20 18:49 ` [PATCH RFC v4 20/42] kmsan: x86: increase stack sizes in KMSAN builds glider
2019-12-30 17:39   ` Arnd Bergmann
2020-01-08 15:31     ` Alexander Potapenko
2019-12-20 18:49 ` [PATCH RFC v4 21/42] kmsan: disable KMSAN instrumentation for certain kernel parts glider
2019-12-20 18:49 ` [PATCH RFC v4 22/42] kmsan: mm: call KMSAN hooks from SLUB code glider
2019-12-20 18:49 ` [PATCH RFC v4 23/42] kmsan: mm: maintain KMSAN metadata for page operations glider
2019-12-20 18:49 ` [PATCH RFC v4 24/42] kmsan: handle memory sent to/from USB glider
2019-12-20 18:49 ` [PATCH RFC v4 25/42] kmsan: handle task creation and exiting glider
2019-12-20 18:49 ` [PATCH RFC v4 26/42] kmsan: net: check the value of skb before sending it to the network glider
2019-12-20 18:49 ` [PATCH RFC v4 27/42] kmsan: printk: treat the result of vscnprintf() as initialized glider
2019-12-20 18:49 ` [PATCH RFC v4 28/42] kmsan: disable instrumentation of certain functions glider
2019-12-20 18:49 ` [PATCH RFC v4 29/42] kmsan: unpoison |tlb| in arch_tlb_gather_mmu() glider
2019-12-20 18:49 ` [PATCH RFC v4 30/42] kmsan: use __msan_ string functions where possible glider
2019-12-20 18:49 ` [PATCH RFC v4 31/42] kmsan: hooks for copy_to_user() and friends glider
2019-12-24  4:50   ` kbuild test robot
2019-12-24  4:50   ` kbuild test robot
2019-12-20 18:49 ` [PATCH RFC v4 32/42] kmsan: init: call KMSAN initialization routines glider
2019-12-20 18:49 ` [PATCH RFC v4 33/42] kmsan: enable KMSAN builds glider
2019-12-20 18:49 ` [PATCH RFC v4 34/42] kmsan: handle /dev/[u]random glider
2019-12-20 18:49 ` [PATCH RFC v4 35/42] kmsan: virtio: check/unpoison scatterlist in vring_map_one_sg() glider
2019-12-20 18:49 ` [PATCH RFC v4 36/42] kmsan: disable strscpy() optimization under KMSAN glider
2019-12-20 18:49 ` [PATCH RFC v4 37/42] kmsan: add iomap support glider
2019-12-20 18:49 ` [PATCH RFC v4 38/42] kmsan: dma: unpoison memory mapped by dma_direct_map_page() glider
2019-12-20 18:49 ` [PATCH RFC v4 39/42] kmsan: disable physical page merging in biovec glider
2019-12-20 18:49 ` [PATCH RFC v4 40/42] kmsan: ext4: skip block merging logic in ext4_mpage_readpages for KMSAN glider
2019-12-20 19:18   ` Eric Biggers
2020-01-08 16:14     ` Alexander Potapenko
2019-12-20 18:49 ` [PATCH RFC v4 41/42] x86: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN glider
2019-12-20 18:49 ` [PATCH RFC v4 42/42] kmsan: x86/uprobes: unpoison regs in arch_uprobe_exception_notify() glider
2019-12-23  7:51 ` [PATCH RFC v4 00/42] Add KernelMemorySanitizer infrastructure Leon Romanovsky
2020-01-09 14:38   ` Alexander Potapenko
2020-01-09 16:29     ` Thomas Gleixner
2020-03-25 11:04       ` Alexander Potapenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191220184955.223741-7-glider@google.com \
    --to=glider@google.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=axboe@kernel.dk \
    --cc=cai@lca.pw \
    --cc=darrick.wong@oracle.com \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=ebiggers@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=ericvh@gmail.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=harry.wentland@amd.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=iii@linux.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=martin.petersen@oracle.com \
    --cc=mhocko@suse.com \
    --cc=mingo@elte.hu \
    --cc=monstr@monstr.eu \
    --cc=mst@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.com \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.