On 2025-08-04 7:33 a.m., Bernd Schubert wrote:
Hi Brian,
sorry for my late reply, just back from vacation and fighting through
my mails.
On 8/4/25 01:33, Brian Song wrote:
On 2025-08-01 12:09 p.m., Brian Song wrote:
Hi Bernd,
We are currently working on implementing termination support for fuse-
over-io_uring in QEMU, and right now we are focusing on how to clean up
in-flight SQEs properly. Our main question is about how well the kernel
supports robust cancellation for these fuse-over-io_uring SQEs. Does it
actually implement cancellation beyond destroying the io_uring queue?
[...]
I have to admit that I'm confused why you can't use umount, isn't that
the most graceful way to shutdown a connection?
If you need another custom way for some reasons, we probably need
to add it.
Thanks,
Bernd
Hi Bernd,
Thanks for your insights!
I think umount doesn't cancel any pending SQEs, right? From what I see,
the only way to cancel all pending SQEs and transition all entries to
the FRRS_USERSPACE state (unavailable for further fuse requests) in the
kernel is by calling io_uring_files_cancel in do_exit, or
io_uring_task_cancel in begin_new_exec.
From my understanding, QEMU follows an event-driven model. So if we
don't cancel the SQEs submitted by a connection when it ends, then
before QEMU exits — after the connection is closed and the associated
FUSE data structures have been freed — any CQE that comes back will
trigger QEMU to invoke a previously deleted CQE handler, leading to a
segfault.
So if the only way to make all pending entries unavailable in the kernel
is calling do_exit or begin_new_exec, I think we should do some
workarounds in QEMU.
Thanks,
Brian
