mn Wed, Sep 03, 2025 at 05:45:27PM +0200, Miklos Szeredi wrote: > On Thu, 21 Aug 2025 at 02:51, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > Create a function to push all the background requests to the queue and > > then wait for the number of pending events to hit zero, and call this > > before fuse_abort_conn. That way, all the pending events are processed > > by the fuse server and we don't end up with a corrupt filesystem. > > The flushing should be dependent on fc->destroy. Without that we > really don't want server to block umount, not even for 30s. <nod> I once thought it was crucial to flush all the FUSE_RELEASE requests to the fuse server prior to the server's ->destroy method being called, but it turns out that's not true -- all the open unlinked files created by generic/488 actually do get cleaned up even in the !fuseblk case. It's just libext2fs that's somewhat stupid and leaves dead dirents all over the root directory, which (mis)lead me into thinking that the unlinked files weren't being cleaned up correctly. > I hate timeout based solutions, so my preference would be to remove > the timeout completely. It wouldn't really make a difference anyway, > since FUSE_DESTROY is sent synchronously without a timeout. Hrmm, the timeouts waiting for FUSE_RELEASE might not be so useful anyway. If someone configured a request_timeout then the requests will automatically cancel if the fuse server wedges itself. OTOH I don't set any request_timeout in fuse[24]fs because they use FUSE_RELEASE to free an open-but-unlinked file, and that can take 45min if (say) you have a file with ten million extents to free as part of freeing the file. I think the problem here is that there's no way for a fuse server to report back to the kernel that it's making progress on a very long running request; and that the kernel probably shouldn't trust that. In the default case there's no request timeout so the kernel will wait forever. In any case, I think I agree that the time_after check isn't necessary. Either we trust the server to be making progress (and do not have a request timeout) or we notice the connection died and move on to aborting all the requests. > Thinking about blocking umount: if we did this in a private user/mount > ns, then it wouldn't be a problem. But how can we be sure? Is > checking sb->s_user_ns != &init_user_ns sufficient? I'm not sure we can -- what if you mount a filesystem in a private mount ns, but then some supervisor process adds another mount to the same sb in the init_user_ns? --D > Thanks, > Miklos >
