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.
signature.asc
Description: PGP signature
