1. 09 5月, 2021 1 次提交
    • P
      io_uring: fix link timeout refs · a298232e
      Pavel Begunkov 提交于
      WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28
      RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28
      Call Trace:
       __refcount_sub_and_test include/linux/refcount.h:283 [inline]
       __refcount_dec_and_test include/linux/refcount.h:315 [inline]
       refcount_dec_and_test include/linux/refcount.h:333 [inline]
       io_put_req fs/io_uring.c:2140 [inline]
       io_queue_linked_timeout fs/io_uring.c:6300 [inline]
       __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354
       io_submit_sqe fs/io_uring.c:6534 [inline]
       io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660
       __do_sys_io_uring_enter fs/io_uring.c:9240 [inline]
       __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182
      
      io_link_timeout_fn() should put only one reference of the linked timeout
      request, however in case of racing with the master request's completion
      first io_req_complete() puts one and then io_put_req_deferred() is
      called.
      
      Cc: stable@vger.kernel.org # 5.12+
      Fixes: 9ae1f8dd ("io_uring: fix inconsistent lock state")
      Reported-by: syzbot+a2910119328ce8e7996f@syzkaller.appspotmail.com
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Link: https://lore.kernel.org/r/ff51018ff29de5ffa76f09273ef48cb24c720368.1620417627.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      a298232e
  2. 06 5月, 2021 1 次提交
  3. 30 4月, 2021 7 次提交
  4. 27 4月, 2021 2 次提交
    • H
      io_uring: maintain drain logic for multishot poll requests · 7b289c38
      Hao Xu 提交于
      Now that we have multishot poll requests, one SQE can emit multiple
      CQEs. given below example:
          sqe0(multishot poll)-->sqe1-->sqe2(drain req)
      sqe2 is designed to issue after sqe0 and sqe1 completed, but since sqe0
      is a multishot poll request, sqe2 may be issued after sqe0's event
      triggered twice before sqe1 completed. This isn't what users leverage
      drain requests for.
      Here the solution is to wait for multishot poll requests fully
      completed.
      To achieve this, we should reconsider the req_need_defer equation, the
      original one is:
      
          all_sqes(excluding dropped ones) == all_cqes(including dropped ones)
      
      This means we issue a drain request when all the previous submitted
      SQEs have generated their CQEs.
      Now we should consider multishot requests, we deduct all the multishot
      CQEs except the cancellation one, In this way a multishot poll request
      behave like a normal request, so:
          all_sqes == all_cqes - multishot_cqes(except cancellations)
      
      Here we introduce cq_extra for it.
      Signed-off-by: NHao Xu <haoxu@linux.alibaba.com>
      Link: https://lore.kernel.org/r/1618298439-136286-1-git-send-email-haoxu@linux.alibaba.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      7b289c38
    • P
      io_uring: Check current->io_uring in io_uring_cancel_sqpoll · 6d042ffb
      Palash Oswal 提交于
      syzkaller identified KASAN: null-ptr-deref Write in
      io_uring_cancel_sqpoll.
      
      io_uring_cancel_sqpoll is called by io_sq_thread before calling
      io_uring_alloc_task_context. This leads to current->io_uring being NULL.
      io_uring_cancel_sqpoll should not have to deal with threads where
      current->io_uring is NULL.
      
      In order to cast a wider safety net, perform input sanitisation directly
      in io_uring_cancel_sqpoll and return for NULL value of current->io_uring.
      This is safe since if current->io_uring isn't set, then there's no way
      for the task to have submitted any requests.
      
      Reported-by: syzbot+be51ca5a4d97f017cd50@syzkaller.appspotmail.com
      Cc: stable@vger.kernel.org
      Signed-off-by: NPalash Oswal <hello@oswalpalash.com>
      Link: https://lore.kernel.org/r/20210427125148.21816-1-hello@oswalpalash.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      6d042ffb
  5. 26 4月, 2021 19 次提交
  6. 23 4月, 2021 1 次提交
  7. 21 4月, 2021 3 次提交
  8. 20 4月, 2021 2 次提交
  9. 18 4月, 2021 3 次提交
  10. 16 4月, 2021 1 次提交