On Mon, Aug 10, 2020 at 11:58 AM syzbot <syzbot+3020eb77f81ef0772fbe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 86cfccb6 Merge tag 'dlm-5.9' of git://git.kernel.org/pub/s.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=171cf11a900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=3757fa75ecfde8e0 > dashboard link: https://syzkaller.appspot.com/bug?extid=3020eb77f81ef0772fbe > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+3020eb77f81ef0772fbe@xxxxxxxxxxxxxxxxxxxxxxxxx > > ================================================================== > BUG: KCSAN: data-race in __io_cqring_fill_event / io_uring_poll > > write to 0xffff8880a04325c0 of 4 bytes by task 12088 on cpu 1: > io_get_cqring fs/io_uring.c:1282 [inline] > __io_cqring_fill_event+0x116/0x430 fs/io_uring.c:1386 > io_cqring_add_event fs/io_uring.c:1420 [inline] > __io_req_complete+0xdb/0x1b0 fs/io_uring.c:1458 > io_complete_rw_common fs/io_uring.c:2208 [inline] > __io_complete_rw+0x2c9/0x2e0 fs/io_uring.c:2289 > kiocb_done fs/io_uring.c:2533 [inline] > io_write fs/io_uring.c:3199 [inline] > io_issue_sqe+0x4fb1/0x7140 fs/io_uring.c:5530 > io_wq_submit_work+0x23e/0x340 fs/io_uring.c:5775 > io_worker_handle_work+0xa69/0xcf0 fs/io-wq.c:527 > io_wqe_worker+0x1f2/0x860 fs/io-wq.c:569 > kthread+0x20d/0x230 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > > read to 0xffff8880a04325c0 of 4 bytes by task 12086 on cpu 0: > io_cqring_events fs/io_uring.c:1937 [inline] > io_uring_poll+0x105/0x140 fs/io_uring.c:7751 > vfs_poll include/linux/poll.h:90 [inline] > __io_arm_poll_handler+0x176/0x3f0 fs/io_uring.c:4735 > io_arm_poll_handler+0x293/0x5c0 fs/io_uring.c:4792 > __io_queue_sqe+0x413/0x760 fs/io_uring.c:5988 > io_queue_sqe+0x81/0x2b0 fs/io_uring.c:6060 > io_submit_sqe+0x333/0x560 fs/io_uring.c:6130 > io_submit_sqes+0x8c6/0xfc0 fs/io_uring.c:6327 > __do_sys_io_uring_enter fs/io_uring.c:8036 [inline] > __se_sys_io_uring_enter+0x1c2/0x720 fs/io_uring.c:7995 > __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:7995 > do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 0 PID: 12086 Comm: syz-executor.5 Not tainted 5.8.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > ================================================================== > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller@xxxxxxxxxxxxxxxx. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. Hi Jens, I wonder if this read of cached_cq_tail needs READ_ONCE as all concurrent access seems to be marked in io_uring.c overall. I also have a concern for a potential bad scenario around cached_cq_tail. I've seen it in other queues. I don't see that it can happen in io_uring, but from a very brief look at the code io_uring may be susceptible, so I thought it's better to ask. The failure is around ordering of reads of head/tail when deciding if the queue is empty or not. Consider: initially queue is empty head==tail==0. One thread adds an element and sets tail=1 and wakes poller. Now, before the poller wakes, several threads push/pop from the queue incrementing both head and tail, maybe also waking poller. But at no point in time the queue is empty. Now poller wakes and reads, say, tail=1 (at the time when head=0 and tail=1 so the queue is not empty) and then reads head=1 (at the time when head=1 and tail=3 so the queue is not empty again). But now the poller looks at head==tail==1 and decides that the queue is empty. This may lead to a missed epoll event and a deadlock. This can be resolved by acquiring a consistent snapshot of head/tail in poller. Is there anything that prevents such a scenario in io_uring? Or it's not an issue for some other reason?
