Jens, I am sorry. I tried to understand your explanations but I can't :/
Just in case, I know nothing about io_uring.
However, I strongly believe that
- the "task_work_exited" check in 4/4 can't help, the kernel
will crash anyway if a task-work callback runs with
current->task_works == &task_work_exited.
- this check is not needed with the patch I sent.
UNLESS io_ring_ctx_wait_and_kill() can be called by the exiting
task AFTER it passes exit_task_work(), but I don't see how this
is possible.
Lets forget this problem, lets assume that task_work_run() is always safe.
I still can not understand why io_ring_ctx_wait_and_kill() needs to call
task_work_run().
On 04/07, Jens Axboe wrote:
>
> io_uring exit removes the pending poll requests, but what if (for non
> exit invocation), we get poll requests completing before they are torn
> down. Now we have task_work queued up that won't get run,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this must not be possible. If task_work is queued it will run, or we
have another bug.
> because we
> are are in the task_work handler for the __fput().
this doesn't matter...
> For this case, we
> need to run the task work.
This is what I fail to understand :/
Oleg.
