Re: [PATCH 1/2] libfuse: don't use SYNC_INIT unless asked for

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

On Tue, May 05, 2026 at 10:17:54AM +0200, Bernd Schubert wrote:
> 
> 
> On 5/5/26 09:30, Bernd Schubert wrote:
> > 
> > 
> > On 5/5/26 07:23, Darrick J. Wong wrote:
> >> From: Darrick J. Wong <djwong@kernel.org>
> >>
> >> If we didn't ask for SYNC_INIT, don't enable it.  This is needed to
> >> maintain compatibility with older fuse servers that only support
> >> asynchronous FUSE_INIT.
> >>
> >> Fixes: 3e1101057aea57 ("fuse mount: Support synchronous FUSE_INIT (privileged daemon)")
> >> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> >> ---
> >>  lib/fuse_lowlevel.c |    6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >>
> >> diff --git a/lib/fuse_lowlevel.c b/lib/fuse_lowlevel.c
> >> index 0e16845d2f14ff..0a801132590079 100644
> >> --- a/lib/fuse_lowlevel.c
> >> +++ b/lib/fuse_lowlevel.c
> >> @@ -4475,9 +4475,9 @@ static int session_start_sync_init(struct fuse_session *se, int fd)
> >>  {
> >>  	int err, res;
> >>  
> >> -	if (!se->want_sync_init &&
> >> -		(se->uring.enable && !fuse_daemonize_is_used())) {
> >> -		if (se->debug)
> >> +	if (!se->want_sync_init) {
> >> +		/* SYNC_INIT is required for io_uring(?) */
> >> +		if ((se->uring.enable && !fuse_daemonize_is_used()) || se->debug)
> >>  			fuse_log(FUSE_LOG_DEBUG,
> >>  					"fuse: sync init not enabled\n");
> >>  		return 0;
> >>
> > 
> > Hmm, but mounting is kind of a libuse internal part? If this is really
> > needed the commit message should mention the exact reason - what is the
> > issue with old fuse servers and sync init?

fuse2fs calls fuse_main, then starts threads from ->init.  It doesn't
call fuse_daemonize_early_start because I haven't ported it to use any
of the new APIs.  I don't have io_uring enabled for fuse on my dev box.

fuse_main calls fuse_session_mount calls fuse_session_mount_new_api
calls session_start_sync_init.  At the start of the function,
se->want_sync_init, se->uring.enable, and daemonize.active are all
false.  The first branch is not taken, so we call FUSE_DEV_IOC_SYNC_INIT
and enable sync_init even though the user didn't ask for that and didn't
prepare for it either.

FUSE_DEV_IOC_SYNC_INIT succeeds, so we send the synchronous FUSE_INIT
from mount, which calls fuse2fs' init() method.  That starts the
background threads and returns.  Upon return to the kernel, the mount()
now succeeds, and the next thing that fuse_main does is call
fuse_daemonize().  Since we didn't call fuse_daemonize_early_start, the
daemonize forks the process and the threads die with the parent.

Looking at that logic a little more, I /think/ you could enable sync
init for fuse servers if they've called fuse_daemonize_early_start even
if they haven't called fuse_session_want_sync_init:

	/*
	 * The fuse server didn't explicitly ask for SYNC_INIT and it
	 * didn't call fuse_daemonize_early_start.  Assume this server
	 * was written before SYNC_INIT and continue using async init.
	 */
	if (!se->want_sync_init && !fuse_daemonize_is_used()) {
		/*
		 * The io_uring backend requires SYNC_INIT because
		 * $reasons, so log a message if we're not enabling
		 * that.
		 */
		if (se->uring.enable)
			fuse_log(..., "io_uring broken with async init");
		else if (se->debug)
			fuse_log(..., "sync init not enabled");
		return 0;
	}

Since (to the extent that I'm familiar with what fuse servers really do
with libfuse) I haven't seen anything that would be a problem.  However
the more cautious thing to do would be to continue using async init
unless fuse_session_want_sync_init is called.

> One reason I can think off is if the ->init() method starts new threads.
> In that case we could still do allow the new mount API when the new
> daemonize API is used.

Yes.  The new mount api still works (modulo patch 2) even if the
SYNC_INIT stuff isn't used.

--D