Re: [PATCH 12/19] fuse mount: Support synchronous FUSE_INIT (privileged daemon)

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

On Wed, Mar 25, 2026 at 08:52:59AM +0100, Bernd Schubert wrote:
> 
> 
> On 3/24/26 23:50, Darrick J. Wong wrote:
> > On Tue, Mar 24, 2026 at 08:42:36PM +0000, Bernd Schubert wrote:
> >> On 3/24/26 01:03, Darrick J. Wong wrote:
> >>> On Mon, Mar 23, 2026 at 06:45:07PM +0100, Bernd Schubert wrote:
> >>>> From: Bernd Schubert <bschubert@ddn.com>
> >>>>
> >>>> Add synchronous FUSE_INIT processing during mount() to
> >>>> enable early daemonization with proper error reporting
> >>>> to the parent process.
> >>>>
> >>>> A new mount thread is needed that handles FUSE_INIT and
> >>>> possible other requests at mount time (like getxattr for selinux).
> >>>> The kernel sends FUSE_INIT during the mount() syscall. Without a thread
> >>>> to process it, mount() blocks forever.
> >>>>
> >>>> Mount thread lifetime:
> >>>> Created before mount() syscall in fuse_start_sync_init_worker()
> >>>> Processes requests until se->mount_finished is set (after mount() returns)
> >>>> Joined after successful mount in fuse_wait_sync_init_completion()
> >>>> Cancelled if mount fails (direct → fusermount3 fallback)
> >>>
> >>> Hrmm, so the main thread (of the child process after daemonization)
> >>> calls mount(), having started a child thread to read and process
> >>> FUSE_INIT + any other mount-related fuse requests?
> >>>
> >>> Later I see an eventfd being used to signal this background thread that
> >>> it should exit and (presumably) let the real request processing queues
> >>> take over.  I'm curious why an eventfd here when pipes were used
> >>> earlier?
> >>
> >> We cannot use eventfds for anything possibly used by BSD - which is
> > 
> > (Yeah, I was wondering about eventfd, but I don't know how quickly
> > libfuse features get ported to BSD so for all I know it could be years
> > until BSD gets SYNC_INIT.)
> > 
> >> fuse_daemonize_ and fusermount. So far sync-init is only in the new
> >> mount API - linux only. We need to switch to a pipe if BSD ever gets that.
> > 
> > I wonder, are the socket communications between fusermount-libfuse
> > considered external interface?  I'm assuming it's not, and you can
> > change it as long as you don't break the other side?
> 
> I know that fusermount3 is also used by other userspace implementations
> like https://github.com/cberner/fuser
> 
> I would need to go through that code to see how it interacts exactly
> (had looked into a few months back, but don't remember the details
> anymore - that were some readmes would be really helpful). My assumption
> is that once we have a released interface in place we cannot easily
> change it anymore.

Heh.  Right, fusermount3 is in a bin directory, so yeah, anyone can exec
it and presumably they won't be happy if it starts speaking gibberish.

With sufficient motivation we could employ the neat systemd hack of
setting xattrs on the socket to proclaim new protocol versions ;)

--D

> 
> Thanks,
> Bernd
>