On Mon, Nov 04, 2024 at 10:31:19AM -0700, Jens Axboe wrote: > 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@xxxxxxxxx> > >>> --- > >>> > >>> 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. I'll add it to btrfs tree, branch for-next and it will be in the main merge window pull request.
