Re: [PATCH] io_uring/cmd: let cmds to know about dying task

[Jens Axboe <axboe@kernel.dk>]

On 11/4/24 9:47 AM, Pavel Begunkov wrote:
> On 11/4/24 16:15, Jens Axboe wrote:
>> On 11/4/24 9:12 AM, Pavel Begunkov wrote:
>>> When the taks that submitted a request is dying, a task work for that
>>> request might get run by a kernel thread or even worse by a half
>>> dismantled task. We can't just cancel the task work without running the
>>> callback as the cmd might need to do some clean up, so pass a flag
>>> instead. If set, it's not safe to access any task resources and the
>>> callback is expected to cancel the cmd ASAP.
>>>
>>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>>> ---
>>>
>>> Made a bit fancier to avoid conflicts. Mark, as before I'd suggest you
>>> to take it and send together with the fix.
>>
>> That's fine, or we can just take it through the io_uring tree, it's not
>> like this matters as both will land before -rc1.
> 
> There should be a btrfs patch that depends on it and I would hope
> it gets squashed into the main patchset or at least goes into the
> same pull and not delayed to rc2.

Right, all I'm saying is that both will land in -rc1 and it doesn't
really matter. Even if it's -rc2 it's not like a potential breakage with
this for certain exiting conditions is an issue. All that really matters
is that the final release is fine.

But like I said, I don't really care - it can go through the btrfs tree
as-is, or I can take it and it'll land in -rc1. If the latter, then I'd
just modify it to use io_should_terminate_tw() fro the get-go, if it
goes via the btrfs tree, then we can do a separate patch for that after
the fact.

I just need to know what the btrfs people intend to do here, so I can
plan accordingly.

-- 
Jens Axboe