On 9/9/25 3:33 PM, Stefan Hajnoczi wrote:
On Fri, Aug 29, 2025 at 10:50:24PM -0400, Brian Song wrote:@@ -901,24 +941,15 @@ static void fuse_export_shutdown(BlockExport *blk_exp) */ g_hash_table_remove(exports, exp->mountpoint); } -} - -static void fuse_export_delete(BlockExport *blk_exp) -{ - FuseExport *exp = container_of(blk_exp, FuseExport, common);- for (int i = 0; i < exp->num_queues; i++) {+ for (size_t i = 0; i < exp->num_queues; i++) { FuseQueue *q = &exp->queues[i];/* Queue 0's FD belongs to the FUSE session */if (i > 0 && q->fuse_fd >= 0) { close(q->fuse_fd);This changes the behavior of the non-io_uring code. Now all fuse fds and fuse_session are closed while requests are potentially still being processed. There is a race condition: if an IOThread is processing a request here then it may invoke a system call on q->fuse_fd just after it has been closed but not set to -1. If another thread has also opened a new file then the fd could be reused, resulting in an accidental write(2) to the new file. I'm not sure whether there is a way to trigger this in practice, but it looks like a problem waiting to happen. Simply setting q->fuse_fd to -1 here doesn't fix the race. It would be necessary to stop processing fuse_fd in the thread before closing it here or to schedule a BH in each thread so that fuse_fd can be closed in the thread that uses the fd.
I get what you mean. This newly introduced cleanup code was originally in the deletion section, after the reconf counter decreased to 0, and it was meant to cancel the pending SQEs. But now we've moved it to the shutdown section, which may introduce a potential problem. How do you think we should fix it? This is the last week of GSoC, I'm already busy on weekdays since the new term has started.
