On Mon, Nov 18, 2024 at 11:55 AM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
>
> On 11/18/24 20:32, Joanne Koong wrote:
> > On Thu, Nov 7, 2024 at 9:04 AM Bernd Schubert <bschubert@xxxxxxx> wrote:
> >>
> >> When the fuse-server terminates while the fuse-client or kernel
> >> still has queued URING_CMDs, these commands retain references
> >> to the struct file used by the fuse connection. This prevents
> >> fuse_dev_release() from being invoked, resulting in a hung mount
> >> point.
> >
> > Could you explain the flow of what happens after a fuse server
> > terminates? How does that trigger the IO_URING_F_CANCEL uring cmd?
>
> This is all about daemon termination, when the mount point is still
> alive. Basically without this patch even plain (non forced umount)
> hangs.
> Without queued IORING_OP_URING_CMDs there is a call into
> fuse_dev_release() on daemon termination, with queued
> IORING_OP_URING_CMDs this doesn't happen as each of these commands
> holds a file reference.
>
> IO_URING_F_CANCEL is triggered from from io-uring, I guess when
> the io-uring file descriptor is released
> (note: 'io-uring fd' != '/dev/fuse fd').
Gotcha. I took a look at the io_uring code and it looks like the call
chain looks something like this:
io_uring_release()
io_ring_ctx_wait_and_kill()
io_ring_exit_work()
io_uring_try_cancel_requests()
io_uring_try_cancel_uring_cmd()
file->f_op->uring_cmd() w/ IO_URING_F_CANCEL issues_flag
>
>
> I guess I need to improve the commit message a bit.
>
>
>
> Cheers,
> Bernd
>
>
>
>
