All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
	Jens Axboe <axboe@kernel.dk>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>,
	Dmitriy Vyukov <dvyukov@google.com>
Subject: Re: null_handle_cmd() doesn't initialize data when reading
Date: Mon, 11 May 2020 15:09:33 +0200	[thread overview]
Message-ID: <CAG_fn=WdBm+P4tQUpyN50XhXF=OhLcGK1=XdDWYYacK4OSqBcg@mail.gmail.com> (raw)
In-Reply-To: <BY5PR04MB69001D14C2318410930ABC03E7A10@BY5PR04MB6900.namprd04.prod.outlook.com>

>
> Can you describe again the problem you are seeing please ? I can't find the
> first email of this thread and forgot what the problem is.
>

Yes, sorry.

The original message was:
>> I'm debugging an issue in nullb driver reported by KMSAN at QEMU startup.
>> There are numerous reports like the one below when checking nullb for
>> different partition types.
>> Basically, read_dev_sector() allocates a cache page which is then
>> wrapped into a bio and passed to the device driver, but never
>> initialized.

>> I've tracked the problem down to a call to null_handle_cmd(cmd,
>> /*sector*/0, /*nr_sectors*/8, /*op*/0).
>> Turns out all the if-branches in this function are skipped, so neither
>> of null_handle_throttled(), null_handle_flush(),
>> null_handle_badblocks(), null_handle_memory_backed(),
>> null_handle_zoned() is executed, and we proceed directly to
>> nullb_complete_cmd().

>> As a result, the pages read from the nullb device are never
>> initialized, at least at boot time.
>> How can we fix this?

Today null_handle_cmd() looks different, but the problem is still manifesting.
KMSAN reports look as follows:

=====================================================
BUG: KMSAN: uninit-value in adfspart_check_ICS+0xb8e/0xde0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc4+ #4177
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77
 dump_stack+0x1c9/0x220 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 adfspart_check_ICS+0xb8e/0xde0 block/partitions/acorn.c:364
 check_partition block/partitions/core.c:140
 blk_add_partitions+0x86a/0x2560 block/partitions/core.c:571
 bdev_disk_changed+0x5c2/0xa30 fs/block_dev.c:1543
 __blkdev_get+0x1195/0x2280 fs/block_dev.c:1646
 blkdev_get+0x219/0x6b0 fs/block_dev.c:1748
 register_disk block/genhd.c:763
 __device_add_disk+0x15b5/0x20a0 block/genhd.c:853
 device_add_disk+0x90/0xa0 block/genhd.c:871
 add_disk ./include/linux/genhd.h:294
 null_gendisk_register drivers/block/null_blk_main.c:1628
 null_add_dev+0x2eaa/0x35d0 drivers/block/null_blk_main.c:1803
 null_init+0x6c5/0xd8d drivers/block/null_blk_main.c:1888
 do_one_initcall+0x4c9/0x930 init/main.c:1160
...
Uninit was created at:
 kmsan_save_stack_with_flags+0x3c/0x90 mm/kmsan/kmsan.c:144
 kmsan_internal_alloc_meta_for_pages mm/kmsan/kmsan_shadow.c:280
 kmsan_alloc_page+0xb9/0x180 mm/kmsan/kmsan_shadow.c:304
 __alloc_pages_nodemask+0xc0e/0x5dd0 mm/page_alloc.c:4848
 __alloc_pages ./include/linux/gfp.h:504
 alloc_page_interleave mm/mempolicy.c:2161
 alloc_pages_current+0x2e7/0x990 mm/mempolicy.c:2293
 alloc_pages ./include/linux/gfp.h:540
 __page_cache_alloc+0x95/0x310 mm/filemap.c:959
 do_read_cache_page+0x293/0x1510 mm/filemap.c:2752
 read_cache_page+0xf3/0x110 mm/filemap.c:2867
 read_mapping_page ./include/linux/pagemap.h:397
 read_part_sector+0x156/0x560 block/partitions/core.c:643
 adfspart_check_ICS+0xa0/0xde0 block/partitions/acorn.c:360
 check_partition block/partitions/core.c:140
 blk_add_partitions+0x86a/0x2560 block/partitions/core.c:571
 bdev_disk_changed+0x5c2/0xa30 fs/block_dev.c:1543
 __blkdev_get+0x1195/0x2280 fs/block_dev.c:1646
 blkdev_get+0x219/0x6b0 fs/block_dev.c:1748
 register_disk block/genhd.c:763
 __device_add_disk+0x15b5/0x20a0 block/genhd.c:853
 device_add_disk+0x90/0xa0 block/genhd.c:871
 add_disk ./include/linux/genhd.h:294
 null_gendisk_register drivers/block/null_blk_main.c:1628
 null_add_dev+0x2eaa/0x35d0 drivers/block/null_blk_main.c:1803
 null_init+0x6c5/0xd8d drivers/block/null_blk_main.c:1888
 do_one_initcall+0x4c9/0x930 init/main.c:1160
=====================================================

  reply	other threads:[~2020-05-11 13:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15 10:16 null_handle_cmd() doesn't initialize data when reading Alexander Potapenko
2019-11-20 23:12 ` Jens Axboe
2019-11-22 11:58   ` Alexander Potapenko
2019-11-25  4:01     ` Chaitanya Kulkarni
2020-05-10 10:03       ` Alexander Potapenko
2020-05-10 16:20         ` Bart Van Assche
2020-05-11 12:58           ` Alexander Potapenko
2020-05-11 13:01             ` Damien Le Moal
2020-05-11 13:09               ` Alexander Potapenko [this message]
2020-05-11 23:18             ` Bart Van Assche
2020-05-12  1:25               ` Bart Van Assche
2020-05-12  1:42                 ` Damien Le Moal
2020-05-12  2:43                   ` Bart Van Assche
2020-05-12  3:23                     ` Damien Le Moal

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='CAG_fn=WdBm+P4tQUpyN50XhXF=OhLcGK1=XdDWYYacK4OSqBcg@mail.gmail.com' \
    --to=glider@google.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=dvyukov@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=willemb@google.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.