• J
    io_uring: drop sqd lock before handling signals for SQPOLL · 82734c5b
    Jens Axboe 提交于
    Don't call into get_signal() with the sqd mutex held, it'll fail if we're
    freezing the task and we'll get complaints on locks still being held:
    
    ====================================
    WARNING: iou-sqp-8386/8387 still has locks held!
    5.12.0-rc4-syzkaller #0 Not tainted
    ------------------------------------
    1 lock held by iou-sqp-8386/8387:
     #0: ffff88801e1d2470 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread+0x24c/0x13a0 fs/io_uring.c:6731
    
     stack backtrace:
     CPU: 1 PID: 8387 Comm: iou-sqp-8386 Not tainted 5.12.0-rc4-syzkaller #0
     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
     Call Trace:
      __dump_stack lib/dump_stack.c:79 [inline]
      dump_stack+0x141/0x1d7 lib/dump_stack.c:120
      try_to_freeze include/linux/freezer.h:66 [inline]
      get_signal+0x171a/0x2150 kernel/signal.c:2576
      io_sq_thread+0x8d2/0x13a0 fs/io_uring.c:6748
    
    Fold the get_signal() case in with the parking checks, as we need to drop
    the lock in both cases, and since we need to be checking for parking when
    juggling the lock anyway.
    
    Reported-by: syzbot+796d767eb376810256f5@syzkaller.appspotmail.com
    Fixes: dbe1bdbb ("io_uring: handle signals for IO threads like a normal thread")
    Signed-off-by: NJens Axboe <axboe@kernel.dk>
    82734c5b
io_uring.c 241.9 KB