Re: [PATCH v2 3/6] fuse: don't require /dev/fuse fd to be kept open during mount

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Mar 16, 2026 at 12:29:53PM +0100, Miklos Szeredi wrote:
> On Sat, 14 Mar 2026 at 00:09, Darrick J. Wong <djwong@kernel.org> wrote:
> 
> > Hrmm, is this https://github.com/libfuse/libfuse/pull/1367 ?
> 
> Right.
> 
> > Which syscall causes the synchronous FUSE_INIT to be sent?  Is it
> > FSCONFIG_CMD_CREATE?
> 
> Yes.
> 
> > > The reason is that while all other threads will exit, the mounting
> > > thread (or process) will keep the device fd open, which will prevent
> > > an abort from happening.
> >
> > So I guess what's happening here is that the main thread calls
> > FSCONFIG_CMD_CREATE, which sends the synchronous FUSE_INIT to the worker
> > pool.  One of the worker threads starts working on the FUSE_INIT reply
> > and crashes.  All the *workers* terminate and close the fuse dev fd,
> > leaving just the main thread.
> >
> > AFAICT, the main thread is stuck in fsconfig() here:
> >
> >         /* Any signal may interrupt this */
> >                 err = wait_event_interruptible(req->waitq,
> >                                 test_bit(FR_FINISHED, &req->flags))
> >
> > so there's still an open ref to the fuse dev fd, which prevents anyone
> > from aborting the FUSE_INIT request so that FR_FINISH gets set?
> 
> Yes.
> 
> >  And now
> > we're just hosed?  Wouldn't the SIGCHLD interrupt the wait?  Or are we
> > stuck someplace else?
> 
> The FUSE_INIT request is in FR_SENT state, and fuse doesn't allow
> interrupting such requests without the cooperation of the server.
> 
> We could special case FUSE_INIT (and probably a number of other
> request types) that are safe to kill without the server's consent.
> Will look into this.

I wonder if there's a way to have a wait_event_killable that will wake
up if the process exits without being killed by a signal?  Or does it
already do that...

> >
> > > This is a regression from the async mount case, where the mount was done
> > > first, and the FUSE_INIT processing afterwards, in which case there's no
> > > such recursive syscall keeping the fd open.
> >
> > Is this hang possible if you're using mount(2) with synchronous
> > FUSE_INIT?
> 
> Yes.

Yikes.  I guess at least there's the echo > .../abort solution below.

> > > The solution is twofold:
> > >
> > >  a) use unshare(CLONE_FILES) in the mounting thread
> >
> > Is this after starting up the worker threads?  I guess that means the
> > worker threads retain their fuse dev fds even though...
> >
> > >     and close the device fd
> > >     after fsconfig(fs_fd, FSCONFIG_SET_STRING, "fd", ...)
> >
> > ...the main thread closes the fuse dev fd before FSCONFIG_CMD_CREATE.
> > What if that main thread needs to use the fuse dev fd after this point?
> > Or, what if userspace doesn't cooperate and unshare()/close()?  Can this
> > hang be broken by kill -9, at least?
> 
> No, only
> 
>   echo > /sys/fs/fuse/connections/NN/abort
> 
> >
> > >  b) only reference the fuse_dev from fs_context not the device file itself
> >
> > Can you set an abort timeout on the FUSE_INIT request?
> 
> I don't like timeouts, but yes, we could.

<nod> Or *some* means of figuring out that one of the other threads has
crashed the process, so we might as well cancel the wait_event?

> >
> > Perhaps my broader question is, what /does/ happen if a fuse server
> > thread starts processing a request and crashes out before replying?  I
> > guess that means the request is never completed, but in the case of
> > !(synchronous FUSE_INIT) we'd just see the whole server terminate, which
> > would then release the fuse dev fd?
> 
> Right.

(I forget, what was the purpose of synchronous FUSE_INIT?)

--D

> Thanks,
> Miklos