Skip to content
Snippets Groups Projects
  • Jens Axboe's avatar
    b6f58a3f
    io_uring: move struct io_kiocb from task_struct to io_uring_task · b6f58a3f
    Jens Axboe authored
    
    Rather than store the task_struct itself in struct io_kiocb, store
    the io_uring specific task_struct. The life times are the same in terms
    of io_uring, and this avoids doing some dereferences through the
    task_struct. For the hot path of putting local task references, we can
    deref req->tctx instead, which we'll need anyway in that function
    regardless of whether it's local or remote references.
    
    This is mostly straight forward, except the original task PF_EXITING
    check needs a bit of tweaking. task_work is _always_ run from the
    originating task, except in the fallback case, where it's run from a
    kernel thread. Replace the potentially racy (in case of fallback work)
    checks for req->task->flags with current->flags. It's either the still
    the original task, in which case PF_EXITING will be sane, or it has
    PF_KTHREAD set, in which case it's fallback work. Both cases should
    prevent moving forward with the given request.
    
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    b6f58a3f
    History
    io_uring: move struct io_kiocb from task_struct to io_uring_task
    Jens Axboe authored
    
    Rather than store the task_struct itself in struct io_kiocb, store
    the io_uring specific task_struct. The life times are the same in terms
    of io_uring, and this avoids doing some dereferences through the
    task_struct. For the hot path of putting local task references, we can
    deref req->tctx instead, which we'll need anyway in that function
    regardless of whether it's local or remote references.
    
    This is mostly straight forward, except the original task PF_EXITING
    check needs a bit of tweaking. task_work is _always_ run from the
    originating task, except in the fallback case, where it's run from a
    kernel thread. Replace the potentially racy (in case of fallback work)
    checks for req->task->flags with current->flags. It's either the still
    the original task, in which case PF_EXITING will be sane, or it has
    PF_KTHREAD set, in which case it's fallback work. Both cases should
    prevent moving forward with the given request.
    
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>