• Jens Axboe's avatar
    io-wq: fix race around pending work on teardown · f5d2d23b
    Jens Axboe authored
    syzbot reports that it's triggering the warning condition on having
    pending work on shutdown:
    
    WARNING: CPU: 1 PID: 12346 at fs/io-wq.c:1061 io_wq_destroy fs/io-wq.c:1061 [inline]
    WARNING: CPU: 1 PID: 12346 at fs/io-wq.c:1061 io_wq_put+0x153/0x260 fs/io-wq.c:1072
    Modules linked in:
    CPU: 1 PID: 12346 Comm: syz-executor.5 Not tainted 5.12.0-rc2-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:io_wq_destroy fs/io-wq.c:1061 [inline]
    RIP: 0010:io_wq_put+0x153/0x260 fs/io-wq.c:1072
    Code: 8d e8 71 90 ea 01 49 89 c4 41 83 fc 40 7d 4f e8 33 4d 97 ff 42 80 7c 2d 00 00 0f 85 77 ff ff ff e9 7a ff ff ff e8 1d 4d 97 ff <0f> 0b eb b9 8d 6b ff 89 ee 09 de bf ff ff ff ff e8 18 51 97 ff 09
    RSP: 0018:ffffc90001ebfb08 EFLAGS: 00010293
    RAX: ffffffff81e16083 RBX: ffff888019038040 RCX: ffff88801e86b780
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000040
    RBP: 1ffff1100b2f8a80 R08: ffffffff81e15fce R09: ffffed100b2f8a82
    R10: ffffed100b2f8a82 R11: 0000000000000000 R12: 0000000000000000
    R13: dffffc0000000000 R14: ffff8880597c5400 R15: ffff888019038000
    FS:  00007f8dcd89c700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055e9a054e160 CR3: 000000001dfb8000 CR4: 00000000001506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     io_uring_clean_tctx+0x1b7/0x210 fs/io_uring.c:8802
     __io_uring_files_cancel+0x13c/0x170 fs/io_uring.c:8820
     io_uring_files_cancel include/linux/io_uring.h:47 [inline]
     do_exit+0x258/0x2340 kernel/exit.c:780
     do_group_exit+0x168/0x2d0 kernel/exit.c:922
     get_signal+0x1734/0x1ef0 kernel/signal.c:2773
     arch_do_signal_or_restart+0x3c/0x610 arch/x86/kernel/signal.c:811
     handle_signal_work kernel/entry/common.c:147 [inline]
     exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
     exit_to_user_mode_prepare+0xac/0x1e0 kernel/entry/common.c:208
     __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
     syscall_exit_to_user_mode+0x48/0x180 kernel/entry/common.c:301
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x465f69
    
    which shouldn't happen, but seems to be possible due to a race on whether
    or not the io-wq manager sees a fatal signal first, or whether the io-wq
    workers do. If we race with queueing work and then send a fatal signal to
    the owning task, and the io-wq worker sees that before the manager sets
    IO_WQ_BIT_EXIT, then it's possible to have the worker exit and leave work
    behind.
    
    Just turn the WARN_ON_ONCE() into a cancelation condition instead.
    
    Reported-by: syzbot+77a738a6bc947bf639ca@syzkaller.appspotmail.com
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    f5d2d23b
io-wq.c 26.2 KB