lkml.org 
[lkml]   [2021]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [syzbot] KCSAN: data-race in sbitmap_queue_clear / sbitmap_queue_clear (3)
On Mon, 25 Oct 2021 at 15:36, Jens Axboe <axboe@kernel.dk> wrote:
[...]
> > write to 0xffffe8ffffd145b8 of 4 bytes by interrupt on cpu 1:
> > sbitmap_queue_clear+0xca/0xf0 lib/sbitmap.c:606
> > blk_mq_put_tag+0x82/0x90
> > __blk_mq_free_request+0x114/0x180 block/blk-mq.c:507
> > blk_mq_free_request+0x2c8/0x340 block/blk-mq.c:541
> > __blk_mq_end_request+0x214/0x230 block/blk-mq.c:565
> > blk_mq_end_request+0x37/0x50 block/blk-mq.c:574
> > lo_complete_rq+0xca/0x170 drivers/block/loop.c:541
> > blk_complete_reqs block/blk-mq.c:584 [inline]
> > blk_done_softirq+0x69/0x90 block/blk-mq.c:589
> > __do_softirq+0x12c/0x26e kernel/softirq.c:558
> > run_ksoftirqd+0x13/0x20 kernel/softirq.c:920
> > smpboot_thread_fn+0x22f/0x330 kernel/smpboot.c:164
> > kthread+0x262/0x280 kernel/kthread.c:319
> > ret_from_fork+0x1f/0x30
> >
> > write to 0xffffe8ffffd145b8 of 4 bytes by interrupt on cpu 0:
> > sbitmap_queue_clear+0xca/0xf0 lib/sbitmap.c:606
> > blk_mq_put_tag+0x82/0x90
> > __blk_mq_free_request+0x114/0x180 block/blk-mq.c:507
> > blk_mq_free_request+0x2c8/0x340 block/blk-mq.c:541
> > __blk_mq_end_request+0x214/0x230 block/blk-mq.c:565
> > blk_mq_end_request+0x37/0x50 block/blk-mq.c:574
> > lo_complete_rq+0xca/0x170 drivers/block/loop.c:541
> > blk_complete_reqs block/blk-mq.c:584 [inline]
> > blk_done_softirq+0x69/0x90 block/blk-mq.c:589
> > __do_softirq+0x12c/0x26e kernel/softirq.c:558
> > run_ksoftirqd+0x13/0x20 kernel/softirq.c:920
> > smpboot_thread_fn+0x22f/0x330 kernel/smpboot.c:164
> > kthread+0x262/0x280 kernel/kthread.c:319
> > ret_from_fork+0x1f/0x30
>
> This is just a per-cpu alloc hint, it's racy by nature. What's the
> preferred way to silence these?

That was my guess, but couldn't quite say. We started looking at
write/write races as more likely to be harmful (vs. just read/write),
and are inclined to let syzbot send out more of such reports. Marking
intentional ones would be ideal so we'll be left with the
unintentional ones.

I would probably use WRITE_ONCE(), just to make sure the compiler
doesn't play games here; or if the code is entirely tolerant to even
the compiler miscompiling things, wrap the thing in data_race().

[ A summary of a bunch of recommendations currently lives here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt
]

Thanks,
-- Marco

\
 
 \ /
  Last update: 2021-10-25 16:31    [W:0.056 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site