Re: [QEMU/FUSE] Discussion on Proper Termination and Async Cancellation in fuse-over-io_uring

[Brian Song <hibriansong@gmail.com>]

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