All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: glider@google.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Theodore Ts'o <tytso@mit.edu>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	Eric Dumazet <edumazet@google.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Takashi Iwai <tiwai@suse.com>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH RFC v1 23/26] kmsan: unpoisoning buffers from devices etc.
Date: Fri, 18 Oct 2019 09:22:22 -0700	[thread overview]
Message-ID: <20191018162222.GM32665@bombadil.infradead.org> (raw)
In-Reply-To: <20191018094304.37056-24-glider@google.com>

On Fri, Oct 18, 2019 at 11:43:01AM +0200, glider@google.com wrote:
> When data is copied to memory from a device KMSAN should treat it as
> initialized. In most cases it's enough to just unpoison the buffer that
> is known to come from a device.
> In the case with __do_page_cache_readahead() and bio_copy_user_iov() we
> have to mark the whole pages as ignored by KMSAN, as it's not obvious
> where these pages are read again.

...

> +++ b/mm/filemap.c
> @@ -18,6 +18,7 @@
>  #include <linux/uaccess.h>
>  #include <linux/capability.h>
>  #include <linux/kernel_stat.h>
> +#include <linux/kmsan-checks.h>
>  #include <linux/gfp.h>
>  #include <linux/mm.h>
>  #include <linux/swap.h>
> @@ -2810,6 +2811,8 @@ static struct page *do_read_cache_page(struct address_space *mapping,
>  		page = wait_on_page_read(page);
>  		if (IS_ERR(page))
>  			return page;
> +		/* Assume all pages in page cache are initialized. */
> +		kmsan_unpoison_shadow(page_address(page), PAGE_SIZE);

Why would you do that?  The page cache already keeps track of which
pages are initialised -- the PageUptodate flag is set on them.  Indeed,
just adding a kmsan call to SetPageUptodate and __SetPageUptodate would
probably be a very straightforward way of handling things, and probably
means you can get rid of a lot of these other calls.



  parent reply	other threads:[~2019-10-18 16:22 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  9:42 [PATCH RFC v1 00/26] Add KernelMemorySanitizer infrastructure glider
2019-10-18  9:42 ` [PATCH RFC v1 01/26] stackdepot: check depot_index before accessing the stack slab glider
2019-10-18  9:42 ` [PATCH RFC v1 02/26] stackdepot: prevent Clang from optimizing away stackdepot_memcmp() glider
2019-10-18  9:42 ` [PATCH RFC v1 03/26] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c glider
2019-10-18  9:42 ` [PATCH RFC v1 04/26] stackdepot: reserve 5 extra bits in depot_stack_handle_t glider
2019-10-18  9:42 ` [PATCH RFC v1 05/26] printk_safe: externalize printk_context glider
2019-10-21  9:09   ` Petr Mladek
2019-10-23 17:57     ` Alexander Potapenko
2019-10-23 18:00       ` Alexander Potapenko
2019-10-24 12:46       ` Petr Mladek
2019-10-28 13:09         ` Alexander Potapenko
2019-10-29 12:02           ` Petr Mladek
2019-10-29 12:45             ` Alexander Potapenko
2019-10-18  9:42 ` [PATCH RFC v1 06/26] kasan: compiler.h: rename __no_kasan_or_inline into __no_memory_tool_or_inline glider
2019-10-18  9:42 ` [PATCH RFC v1 07/26] kmsan: add ReST documentation glider
2019-10-18  9:42 ` [PATCH RFC v1 08/26] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW glider
2019-10-18  9:42 ` [PATCH RFC v1 09/26] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ glider
2019-10-18  9:42 ` [PATCH RFC v1 10/26] kmsan: reduce vmalloc space glider
2019-10-18  9:42 ` [PATCH RFC v1 11/26] kmsan: add KMSAN runtime glider
2019-10-18  9:42 ` [PATCH RFC v1 12/26] kmsan: x86: sync metadata pages on page fault glider
2019-10-18  9:42 ` [PATCH RFC v1 13/26] kmsan: add tests for KMSAN glider
2019-10-18  9:42 ` [PATCH RFC v1 14/26] kmsan: make READ_ONCE_TASK_STACK() return initialized values glider
2019-10-18  9:42 ` [PATCH RFC v1 15/26] kmsan: Kconfig changes to disable options incompatible with KMSAN glider
2019-10-21 14:11   ` Harry Wentland
2019-10-18  9:42 ` [PATCH RFC v1 16/26] kmsan: Changing existing files to enable KMSAN builds glider
2019-10-18  9:42 ` [PATCH RFC v1 17/26] kmsan: disable KMSAN instrumentation for certain kernel parts glider
2019-10-18  9:42 ` [PATCH RFC v1 18/26] kmsan: mm: call KMSAN hooks from SLUB code glider
2019-10-18 13:22   ` Qian Cai
2019-10-18 13:33     ` Alexander Potapenko
2019-10-18 13:41       ` Qian Cai
2019-10-18 13:55         ` Alexander Potapenko
2019-10-18 14:42           ` Qian Cai
2019-10-18 14:54             ` Alexander Potapenko
2019-10-18 15:13               ` Qian Cai
2019-10-18 15:30                 ` Alexander Potapenko
2019-10-18 16:08                   ` Qian Cai
2019-10-18  9:42 ` [PATCH RFC v1 19/26] kmsan: call KMSAN hooks where needed glider
2019-10-18 15:02   ` Qian Cai
2019-10-29 14:09     ` Alexander Potapenko
2019-10-29 14:56       ` Qian Cai
2019-10-21  9:25   ` Petr Mladek
2019-10-29 13:59     ` Alexander Potapenko
2019-10-18  9:42 ` [PATCH RFC v1 20/26] kmsan: disable instrumentation of certain functions glider
2019-10-18  9:42 ` [PATCH RFC v1 21/26] kmsan: unpoison |tlb| in arch_tlb_gather_mmu() glider
2019-10-18  9:43 ` [PATCH RFC v1 22/26] kmsan: use __msan_memcpy() where possible glider
2019-10-18  9:43 ` [PATCH RFC v1 23/26] kmsan: unpoisoning buffers from devices etc glider
2019-10-18 15:27   ` Christoph Hellwig
2019-10-18 16:22   ` Matthew Wilcox [this message]
2019-10-29 14:45     ` Alexander Potapenko
2019-10-30 12:43       ` Alexander Potapenko
2019-10-18  9:43 ` [PATCH RFC v1 24/26] kmsan: hooks for copy_to_user() and friends glider
2019-10-18  9:43 ` [PATCH RFC v1 25/26] kmsan: disable strscpy() optimization under KMSAN glider
2019-10-18  9:43 ` [PATCH RFC v1 26/26] net: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN glider
2019-10-19  3:20   ` Randy Dunlap

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=20191018162222.GM32665@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=ericvh@gmail.com \
    --cc=glider@google.com \
    --cc=hch@lst.de \
    --cc=linux-mm@kvack.org \
    --cc=martin.petersen@oracle.com \
    --cc=mst@redhat.com \
    --cc=tiwai@suse.com \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@oracle.com \
    /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.