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'). I guess I need to improve the commit message a bit. Cheers, Bernd
