1. 06 7月, 2020 4 次提交
    • P
      io_uring: fix mis-refcounting linked timeouts · 6df1db6b
      Pavel Begunkov 提交于
      io_prep_linked_timeout() sets REQ_F_LINK_TIMEOUT altering refcounting of
      the following linked request. After that someone should call
      io_queue_linked_timeout(), otherwise a submission reference of the linked
      timeout won't be ever dropped.
      
      That's what happens in io_steal_work() if io-wq decides to postpone linked
      request with io_wqe_enqueue(). io_queue_linked_timeout() can also be
      potentially called twice without synchronisation during re-submission,
      e.g. io_rw_resubmit().
      
      There are the rules, whoever did io_prep_linked_timeout() must also call
      io_queue_linked_timeout(). To not do it twice, io_prep_linked_timeout()
      will return non NULL only for the first call. That's controlled by
      REQ_F_LINK_TIMEOUT flag.
      
      Also kill REQ_F_QUEUE_TIMEOUT.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      6df1db6b
    • J
      io_uring: use new io_req_task_work_add() helper throughout · c2c4c83c
      Jens Axboe 提交于
      Since we now have that in the 5.9 branch, convert the existing users of
      task_work_add() to use this new helper.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c2c4c83c
    • J
      io_uring: abstract out task work running · 4c6e277c
      Jens Axboe 提交于
      Provide a helper to run task_work instead of checking and running
      manually in a bunch of different spots. While doing so, also move the
      task run state setting where we run the task work. Then we can move it
      out of the callback helpers. This also helps ensure we only do this once
      per task_work list run, not per task_work item.
      Suggested-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      4c6e277c
    • J
      Merge branch 'io_uring-5.8' into for-5.9/io_uring · 58c6a581
      Jens Axboe 提交于
      Pull in task_work changes from the 5.8 series, as we'll need to apply
      the same kind of changes to other parts in the 5.9 branch.
      
      * io_uring-5.8:
        io_uring: fix regression with always ignoring signals in io_cqring_wait()
        io_uring: use signal based task_work running
        task_work: teach task_work_add() to do signal_wake_up()
      58c6a581
  2. 05 7月, 2020 1 次提交
    • J
      io_uring: fix regression with always ignoring signals in io_cqring_wait() · b7db41c9
      Jens Axboe 提交于
      When switching to TWA_SIGNAL for task_work notifications, we also made
      any signal based condition in io_cqring_wait() return -ERESTARTSYS.
      This breaks applications that rely on using signals to abort someone
      waiting for events.
      
      Check if we have a signal pending because of queued task_work, and
      repeat the signal check once we've run the task_work. This provides a
      reliable way of telling the two apart.
      
      Additionally, only use TWA_SIGNAL if we are using an eventfd. If not,
      we don't have the dependency situation described in the original commit,
      and we can get by with just using TWA_RESUME like we previously did.
      
      Fixes: ce593a6c ("io_uring: use signal based task_work running")
      Cc: stable@vger.kernel.org # v5.7
      Reported-by: NAndres Freund <andres@anarazel.de>
      Tested-by: NAndres Freund <andres@anarazel.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b7db41c9
  3. 01 7月, 2020 2 次提交
    • J
      io_uring: use signal based task_work running · ce593a6c
      Jens Axboe 提交于
      Since 5.7, we've been using task_work to trigger async running of
      requests in the context of the original task. This generally works
      great, but there's a case where if the task is currently blocked
      in the kernel waiting on a condition to become true, it won't process
      task_work. Even though the task is woken, it just checks whatever
      condition it's waiting on, and goes back to sleep if it's still false.
      
      This is a problem if that very condition only becomes true when that
      task_work is run. An example of that is the task registering an eventfd
      with io_uring, and it's now blocked waiting on an eventfd read. That
      read could depend on a completion event, and that completion event
      won't get trigged until task_work has been run.
      
      Use the TWA_SIGNAL notification for task_work, so that we ensure that
      the task always runs the work when queued.
      
      Cc: stable@vger.kernel.org # v5.7
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ce593a6c
    • O
      task_work: teach task_work_add() to do signal_wake_up() · e91b4816
      Oleg Nesterov 提交于
      So that the target task will exit the wait_event_interruptible-like
      loop and call task_work_run() asap.
      
      The patch turns "bool notify" into 0,TWA_RESUME,TWA_SIGNAL enum, the
      new TWA_SIGNAL flag implies signal_wake_up().  However, it needs to
      avoid the race with recalc_sigpending(), so the patch also adds the
      new JOBCTL_TASK_WORK bit included in JOBCTL_PENDING_MASK.
      
      TODO: once this patch is merged we need to change all current users
      of task_work_add(notify = true) to use TWA_RESUME.
      
      Cc: stable@vger.kernel.org # v5.7
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      e91b4816
  4. 30 6月, 2020 15 次提交
  5. 29 6月, 2020 1 次提交
  6. 28 6月, 2020 14 次提交
  7. 27 6月, 2020 3 次提交
    • R
      io_uring: fix function args for !CONFIG_NET · 1e16c2f9
      Randy Dunlap 提交于
      Fix build errors when CONFIG_NET is not set/enabled:
      
      ../fs/io_uring.c:5472:10: error: too many arguments to function ‘io_sendmsg’
      ../fs/io_uring.c:5474:10: error: too many arguments to function ‘io_send’
      ../fs/io_uring.c:5484:10: error: too many arguments to function ‘io_recvmsg’
      ../fs/io_uring.c:5486:10: error: too many arguments to function ‘io_recv’
      ../fs/io_uring.c:5510:9: error: too many arguments to function ‘io_accept’
      ../fs/io_uring.c:5518:9: error: too many arguments to function ‘io_connect’
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: io-uring@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      1e16c2f9
    • J
      Merge branch 'io_uring-5.8' into for-5.9/io_uring · 2237d765
      Jens Axboe 提交于
      Merge in changes that went into 5.8-rc3. GIT will silently do the
      merge, but we still need a tweak on top of that since
      io_complete_rw_common() was modified to take a io_comp_state pointer.
      The auto-merge fails on that, and we end up with something that
      doesn't compile.
      
      * io_uring-5.8:
        io_uring: fix current->mm NULL dereference on exit
        io_uring: fix hanging iopoll in case of -EAGAIN
        io_uring: fix io_sq_thread no schedule when busy
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      2237d765
    • P
      io-wq: return next work from ->do_work() directly · f4db7182
      Pavel Begunkov 提交于
      It's easier to return next work from ->do_work() than
      having an in-out argument. Looks nicer and easier to compile.
      Also, merge io_wq_assign_next() into its only user.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      f4db7182