public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd@bsbernd.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
	Joanne Koong <joannelkoong@gmail.com>, Kevin Chen <kchen@ddn.com>
Subject: Re: [PATCH v2 24/25] Add mount and daemonization README documents
Date: Mon, 20 Apr 2026 02:21:34 +0200	[thread overview]
Message-ID: <aead083a-ff23-43b7-8fd5-ce543ea4d969@bsbernd.com> (raw)
In-Reply-To: <20260331011740.GJ6202@frogsfrogsfrogs>



On 3/31/26 03:17, Darrick J. Wong wrote:
> On Thu, Mar 26, 2026 at 10:34:57PM +0100, Bernd Schubert wrote:
>> These are useful to
>>
>> Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
>> ---
>>  doc/README.daemonize  | 197 +++++++++++++++++++++++++++
>>  doc/README.fusermount | 362 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  doc/README.mount      |  86 ++++++++++++
>>  doc/README.sync-init  | 184 +++++++++++++++++++++++++
>>  4 files changed, 829 insertions(+)
>>
>> diff --git a/doc/README.daemonize b/doc/README.daemonize
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..7b56c33077f29edbd335a2778120d9b6db6022ad
>> --- /dev/null
>> +++ b/doc/README.daemonize
>> @@ -0,0 +1,197 @@
>> +FUSE Daemonization API
>> +======================
>> +
>> +This document describes the FUSE daemonization APIs, including the legacy
>> +fuse_daemonize() function and the new fuse_daemonize_start()/signal() API
>> +introduced in libfuse 3.19.
>> +
>> +
>> +Overview
>> +--------
>> +
>> +FUSE filesystems often need to run as background daemons. Daemonization
>> +involves forking the process, creating a new session, and redirecting
>> +standard file descriptors. The challenge is properly reporting initialization
>> +failures to the parent process.
> 
> But why is it important to report init failures to the parent?
> 
> "The parent can, in turn, pass those errors up to whichever process
> started the fuse server."?
> 
>> +
>> +
>> +Old API: fuse_daemonize()
>> +--------------------------
>> +
>> +Function signature:
>> +    int fuse_daemonize(int foreground);
>> +
>> +Location: lib/helper.c
>> +
>> +This is the legacy daemonization API, primarily used with the high-level
>> +fuse_main() interface.
>> +
>> +Behavior:
>> +- If foreground=0: forks the process, creates a new Unix session,
>> +  redirects stdio
>> +- If foreground=1: only changes directory to "/"
>> +- Parent waits for a single byte on a pipe before exiting
>> +- Child writes completion byte immediately after redirecting stdio
>> +- Always changes directory to "/"
>> +
>> +Limitations:
>> +1. No failure reporting: The parent receives notification immediately after
>> +   fork/setsid, before any meaningful initialization (like mounting the
>> +   filesystem or starting threads).
>> +
>> +2. Timing constraint: Must be called AFTER fuse_session_mount() in existing
>> +   examples, because there's no way to report mount failures to the parent.
> 
> "...to report mount() failures...", specifically.
> 
>> +
>> +3. Thread initialization: Cannot report failures from complex initialization
>> +   steps like:
>> +   - Starting worker threads
>> +   - Network connection setup
>> +   - RDMA memory registration
>> +   - Resource allocation
>> +
>> +4. FUSE_SYNC_INIT incompatibility: With the FUSE_SYNC_INIT feature, FUSE_INIT
>> +   happens at mount time and may start io_uring threads. This requires
>> +   daemonization BEFORE mount, which the old API cannot handle properly.
>> +
>> +Example usage (old API):
>> +    fuse = fuse_new(...);
>> +    fuse_mount(fuse, mountpoint);
>> +    fuse_daemonize(opts.foreground);  // After mount, can't report mount failure
>> +    fuse_set_signal_handlers(se);
>> +    fuse_session_loop(se);
>> +
>> +
>> +New API: fuse_daemonize_start() / fuse_daemonize_success() / fuse_daemonize_fail()
>> +---------------------------------------------------------------------------------
>> +
>> +Functions:
>> +    int fuse_daemonize_start(unsigned int flags);
>> +    void fuse_daemonize_success(void);
>> +    void fuse_daemonize_fail(void);
>> +    bool fuse_daemonize_active(void);
>> +
>> +Location: lib/fuse_daemonize.c, include/fuse_daemonize.h
>> +Available since: libfuse 3.19
>> +
>> +This new API solves the limitations of fuse_daemonize() by splitting
>> +daemonization into two phases:
>> +
>> +1.   fuse_daemonize_start() - Fork and setup, but parent waits
>> +2.1. fuse_daemonize_fail() - Signal failure to parent
>> +2.2  fuse_daenmize_success() - Signal startup to success to the parent
> 
> fuse_daemonize_success()
> 
>> +     See below for an important detail.
>> +
>> +
>> +fuse_daemonize_start()
>> +----------------------
>> +
>> +Flags:
>> +- FUSE_DAEMONIZE_NO_CHDIR: Don't change directory to "/"
>> +- FUSE_DAEMONIZE_NO_BACKGROUND: Don't fork (foreground mode)
>> +
>> +Behavior:
>> +- Unless NO_BACKGROUND: forks the process
>> +- Parent waits for status signal from child
>> +- Child creates new session and continues
>> +- Unless NO_CHDIR: changes directory to "/"
>> +- Closes stdin immediately in child
>> +- Starts a watcher thread to detect parent death
>> +- Returns 0 in child on success, negative errno on error
>> +
>> +Parent death detection:
>> +- Uses a "death pipe" - parent keeps write end open
>> +- Child's watcher thread polls the read end
>> +- When parent dies, pipe gets POLLHUP and child exits
> 
> "If parent dies"?  Using the word "when" make it sound like the parent
> is supposed to die before the child.
> 
>> +- Prevents orphaned daemons if parent is killed
> 
> If the child dies unexpectedly, the read(signal_pipe[0], ...) call
> returns zero, so the parent will also exit, right?  I think that should
> be mentioned here.
> 
>> +
>> +
>> +fuse_daemonize_fail(int err)
>> +----------------------------
>> +
>> +Behavior:
>> +- Signals the parent about the provided error
>> +- Parent will exit with that error
>> +
>> +fuse_daemonize_success()
>> +------------------------
>> +- Signals the parent process with succes
>> +- On success: redirects stdout/stderr to /dev/null
> 
> For systemd service mode, it'd be nice to have a third flag that
> disables stdout/stderr redirection too, since it's expected in systemd
> land that stdout goes to journald/syslog.  I can add that in my own
> patchset.

I have definitely planned that, but please feel free to add it. I
frequently need stdout/err in syslog for ASAN runs.
I had patch/PR for passthrough_hp, but didn't like it and recently
closed the PR, because can be generalized with new daemonize API.

> 
>> +- Stops the parent watcher thread
>> +- Cleans up pipes and internal state
>> +- Safe to call multiple times
>> +- Safe to call even if fuse_daemonize_start() failed
>> +- *Important*: Should be called twice, once from ->init
>> +  (struct fuse_lowlevel_ops::init or for high level interface
>> +   struct fuse_operations::init) and after fuse_session_mount().
>> +  It will internally figure out which of these two calls will
>> +  actually signal the parent about success. Reason is that
>> +  sucess must only be signaled when the mount is complete and
> 
> success ^^^
> 
>> +  that depends on if synchronous or asynchronous FUSE_INIT is
>> +  used. 
>> +
>> +
>> +fuse_daemonize_active()
>> +-----------------------
>> +
>> +Returns true if daemonization is active and waiting for signal.
>> +
>> +Used by the high-level fuse_main() to detect if the application already
>> +called the new API, avoiding double-daemonization.
>> +
>> +
>> +Example usage (new API):
>> +-------------------------
>> +
>> +    // Start daemonization BEFORE mount
>> +    unsigned int daemon_flags = 0;
>> +    if (foreground)
>> +        daemon_flags |= FUSE_DAEMONIZE_NO_BACKGROUND;
>> +
>> +    if (fuse_daemonize_start(daemon_flags) != 0)
>> +        goto error;
>> +
>> +    // Complex initialization can fail and be reported
>> +    if (setup_threads() != 0)
>> +        goto error_signal;
>> +
>> +    if (setup_network() != 0)
>> +        goto error_signal;
>> +    // Mount can now fail and be reported to parent
>> +    if (fuse_session_mount(se, mountpoint) != 0)
>> +        goto error_signal;
>> +
>> +    // Signal success - parent exits with EXIT_SUCCESS
>> +    // This is typically done in the init() callback after FUSE_INIT
>> +    fuse_daemonize_signal(FUSE_DAEMONIZE_SUCCESS);
>> +
>> +    // Run main loop
>> +    fuse_session_loop(se);
>> +
>> +    return 0;
>> +
>> +error_signal:
>> +    // Signal failure - parent exits with EXIT_FAILURE
>> +    fuse_daemonize_signal(FUSE_DAEMONIZE_FAILURE);
>> +error:
>> +    return 1;
>> +
>> +
>> +When to signal success
>> +----------------------
>> +
>> +The success signal should be sent after all critical initialization is
>> +complete. For FUSE filesystems, this is typically in the init() callback,
>> +after FUSE_INIT has been processed successfully.
>> +
>> +Example (from passthrough_hp.cc):
>> +    static void sfs_init(void *userdata, fuse_conn_info *conn) {
>> +        // ... initialization ...
>> +        fuse_daemonize_signal(FUSE_DAEMONIZE_SUCCESS);
>> +    }
>> +
>> +This ensures the parent only exits after:
>> +- Mount succeeded
>> +- FUSE_INIT completed
>> +- All threads started
>> +- Filesystem is ready to serve requests
>> +
>> diff --git a/doc/README.fusermount b/doc/README.fusermount
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..5b81651c8690aa25fef12db322af977c9cba1d31
>> --- /dev/null
>> +++ b/doc/README.fusermount
>> @@ -0,0 +1,362 @@
>> +Synchronous FUSE_INIT Protocol
>> +================================
> 
> Hm.  I thought I just got done reading a documnet about how synchronous
> FUSE_INIT works?  Looking at the copious references to fusermount3 under
> "Protocol Flow", is this the doc for how it works when fusermount is
> involved?
> 
>> +
>> +Overview
>> +--------
>> +
>> +The sync-init feature enables the FUSE library to start worker threads and
>> +perform initialization ioctl calls BEFORE the actual mount() syscall happens.
>> +This is required for the kernel's synchronous FUSE_INIT feature, where the
>> +mount() syscall blocks until the FUSE daemon processes the INIT request.
>> +
>> +Without this feature, there would be a deadlock:
>> +- mount() blocks waiting for INIT response
>> +- Worker threads can't start because mount() hasn't returned
>> +- INIT request can't be processed because worker threads aren't running
>> +
>> +
>> +Protocol Flow
>> +-------------
>> +
>> +Traditional mount flow:
>> +  1. Library calls fusermount3
>> +  2. fusermount3 opens /dev/fuse
>> +  3. fusermount3 performs mount() syscall
>> +  4. fusermount3 sends fd to library
>> +  5. Library starts worker threads
>> +  6. Worker threads process FUSE requests
>> +
>> +Sync-init mount flow:
>> +  1. Library calls fusermount3 with --sync-init flag
>> +  2. fusermount3 opens /dev/fuse
>> +  3. fusermount3 sends fd to library
>> +  4. Library receives fd
>> +  5. Library performs FUSE_DEV_IOC_SYNC_INIT ioctl
>> +  6. Library starts worker threads
>> +  7. Library sends "proceed" signal to fusermount3
>> +  8. fusermount3 performs mount() syscall (blocks until INIT completes)
>> +  9. Worker threads process INIT request
>> +  10. mount() syscall completes
>> +  11. fusermount3 exits
>> +
>> +
>> +Implementation Details
>> +----------------------
>> +
>> +Bidirectional Communication:
>> +  - Uses the existing unix socket (_FUSE_COMMFD environment variable)
>> +  - Simple 1-byte protocol for signaling
>> +  - Library signals fusermount3 when ready to proceed with mount
>> +
>> +fusermount3 Changes:
>> +  - New --sync-init command-line option
>> +  - Split mount operation into two phases:
>> +    * mount_fuse_prepare(): Opens device, prepares parameters
>> +    * mount_fuse_finish_fsmount(): Performs actual mount() syscall
>> +  - wait_for_signal(): Waits for library to signal readiness
>> +  - struct mount_context: Preserves state between phases
>> +
>> +Library Changes:
>> +  - fuse_session_mount_new_api(): Uses new protocol when available
>> +  - Sends "proceed" signal after worker thread is ready
>> +  - Handles both old and new mount protocols for compatibility
>> +
>> +
>> +Backward Compatibility
>> +----------------------
>> +
>> +The implementation maintains full backward compatibility:
>> +  - Old library + new fusermount3: Works (uses traditional flow)
>> +  - New library + old fusermount3: Falls back to traditional flow
> 
> "traditional", as in async FUSE_INIT?
> 
>> +  - New library + new fusermount3: Uses sync-init flow when appropriate
>> +
>> +
>> +Error Handling
>> +--------------
>> +
>> +If any step fails during the sync-init flow:
>> +  - fusermount3 closes the fd and exits with error
>> +  - Library detects failure and cleans up
>> +  - No mount is left in inconsistent state
>> +
>> +Connection closure:
>> +  - If library closes socket before signaling, fusermount3 detects and exits
>> +  - If fusermount3 crashes, library detects closed socket
>> +
>> +
>> +Security Considerations
>> +-----------------------
>> +
>> +The sync-init protocol does not introduce new security concerns:
>> +  - Uses the same privilege separation as traditional mount
>> +  - Socket communication is already established and trusted
>> +  - No new privileged operations are added
>> +  - File descriptor passing uses existing SCM_RIGHTS mechanism
>> +
>> +
>> +Performance Impact
>> +------------------
>> +
>> +Minimal performance impact:
>> +  - One additional recv() call in fusermount3
>> +  - One additional send() call in library
>> +  - Total overhead: ~2 context switches
>> +  - Only affects mount time, not runtime performance
>> +
>> +
>> +Future Enhancements
>> +-------------------
>> +
>> +Potential improvements:
>> +  - Extended protocol for more complex initialization sequences
>> +  - Support for multiple worker threads coordination
>> +  - Enhanced error reporting through the socket
>> +  - Timeout mechanisms for detecting hung initialization
> 
> Is that for libfuse detecting that a fusermount has hung?  Or for
> fusermount detecting that the fuse server hasn't responded to FUSE_INIT
> and giving up?  I suspect the former.
> 
>> +
>> +
>> +ASCII Workflow Diagrams
>> +========================
>> +
>> +1. Traditional Mount Flow (without --sync-init, async INIT)
>> +------------------------------------------------------------
>> +
>> +Library                   fusermount3              Kernel
>> +   |                           |                      |
>> +   |--- spawn fusermount3 ---->|                      |
>> +   |                           |                      |
>> +   |                      [open /dev/fuse]            |
>> +   |                           |------- open -------->|
>> +   |                           |<------ fd ---------- |
>> +   |                           |                      |
>> +   |                      [mount() syscall]           |
>> +   |                           |------ mount -------->|
>> +   |                           |<----- success ------ | [mount returns immediately]
>> +   |                           |                      | [INIT queued in kernel]
>> +   |                      [send_fd(fd)]               |
>> +   |<------- fd --------------|                      |
>> +   |                           |                      |
>> +   |                      [fusermount3 exits]         |
>> +   |                                                  |
>> +   |  [start worker thread]                          |
>> +   |  [worker reads /dev/fuse]                       |
>> +   |---------------------------------------- read -->|
>> +   |<--------------------------------------- INIT ---| [dequeued from kernel]
>> +   |                                                  |
>> +   | OK: INIT was queued, worker reads it later      |
>> +   |     Works fine for async INIT                   |
>> +
>> +
>> +1b. Problem: Synchronous INIT without --sync-init
>> +--------------------------------------------------
>> +
>> +Library                   fusermount3              Kernel
>> +   |                           |                      |
>> +   |--- spawn fusermount3 ---->|                      |
>> +   |                           |                      |
>> +   |                      [open /dev/fuse]            |
>> +   |                           |------- open -------->|
>> +   |                           |<------ fd ---------- |
>> +   |                           |                      |
>> +   |                      [mount() syscall]           |
>> +   |                           |------ mount -------->|
>> +   |                           |                      | [mount BLOCKS waiting for INIT]
>> +   |                           | (BLOCKED)            | [needs worker to process INIT]
>> +   |                           |                      |
>> +   |  [waiting for fd...]      |                      |
>> +   |                           |                      |
>> +   |                           |                      |
>> +   | DEADLOCK: mount() waits for INIT response       |
>> +   |           but worker thread not started yet     |
>> +   |           because we're waiting for fd          |
>> +
>> +
>> +2. Sync-Init Mount Flow (with --sync-init)
>> +-------------------------------------------
>> +
>> +Library                   fusermount3              Kernel
>> +   |                           |                      |
>> +   |--- spawn fusermount3 ---->|                      |
>> +   |    with --sync-init       |                      |
>> +   |                           |                      |
>> +   |                      [open /dev/fuse]            |
>> +   |                           |------- open -------->|
>> +   |                           |<------ fd ---------- |
>> +   |                           |                      |
>> +   |                      [send_fd(fd)]               |
>> +   |<------- fd --------------|                      |
>> +   |                           |                      |
>> +   |                      [wait_for_signal()]         |
>> +   |                           | (BLOCKED)            |
>> +   |                           |                      |
>> +   |  [ioctl SYNC_INIT]        |                      |
>> +   |---------------------------------------- ioctl -->|
>> +   |                                                  |
>> +   |  [start worker thread]                          |
>> +   |  [worker ready]                                 |
>> +   |                           |                      |
>> +   |--- "proceed" signal ----->|                      |
>> +   |                      [signal received]           |
>> +   |                           |                      |
>> +   |                      [mount() syscall]           |
>> +   |                           |------ mount -------->|
>> +   |                           |                      | [mount blocks]
>> +   |                           |                      | [sends INIT]
>> +   |<------------------------------------------------ |
>> +   |                           |                      |
>> +   | [worker processes INIT]   |                      |
>> +   |------------------------------------------------->|
>> +   |                           |                      | [mount unblocks]
>> +   |                           |<----- success ------ |
>> +   |                           |                      |
>> +   |                      [fusermount3 exits]         |
>> +   |                                                  |
>> +   | SUCCESS: Worker ready before mount()            |
>> +   |          INIT processed synchronously           |
>> +
>> +
>> +3. Error Scenario: Library Crashes Before Signaling
>> +----------------------------------------------------
>> +
>> +Library                   fusermount3              Kernel
>> +   |                           |                      |
>> +   |--- spawn fusermount3 ---->|                      |
>> +   |    with --sync-init       |                      |
>> +   |                           |                      |
>> +   |                      [open /dev/fuse]            |
>> +   |                           |------- open -------->|
>> +   |                           |<------ fd ---------- |
>> +   |                           |                      |
>> +   |                      [send_fd(fd)]               |
>> +   |<------- fd --------------|                      |
>> +   |                           |                      |
>> +   |                      [wait_for_signal()]         |
>> +   |                           | (BLOCKED)            |
>> +   |                           |                      |
>> +   X  [library crashes]        |                      |
>> +   |                           |                      |
>> +   |                      [recv() returns 0]          |
>> +   |                      [socket closed]             |
>> +   |                           |                      |
>> +   |                      [cleanup and exit]          |
>> +   |                           X                      |
>> +   |                                                  |
>> +   | RESULT: Clean failure, no mount performed       |
>> +
>> +
>> +4. Detailed Function Call Flow
>> +-------------------------------
>> +
>> +Library (lib/fuse_lowlevel.c):
>> +fuse_session_mount_new_api()
>> +   |
>> +   +-- fuse_kern_mount_prepare()  [lib/mount.c]
>> +   |      |
>> +   |      +-- fuse_mount_fusermount()  [lib/mount_util.c]
>> +   |             |
>> +   |             +-- socketpair()  [create comm socket]
>> +   |             |
>> +   |             +-- fork()
>> +   |             |
>> +   |             +-- [child] execl("fusermount3", "--sync-init", ...)
>> +   |             |
>> +   |             +-- [parent] receive_fd()  <--- BLOCKS until fd arrives
>> +   |                    |
>> +   |                    +-- recvmsg(SCM_RIGHTS)
>> +   |                    |
>> +   |                    +-- return fd
>> +   |
>> +   +-- session_start_sync_init()  [lib/fuse_lowlevel.c]
>> +   |      |
>> +   |      +-- ioctl(fd, FUSE_DEV_IOC_SYNC_INIT)
>> +   |      |
>> +   |      +-- pthread_create(worker_thread)
>> +   |      |
>> +   |      +-- return
>> +   |
>> +   +-- fuse_fusermount_proceed_mnt(socket)  [lib/mount.c] <--- NEW: Bidirectional handshake
>> +          |
>> +          +-- send(socket, "proceed", 1)  <--- Signal fusermount3 to proceed
>> +          |
>> +          +-- recv(socket, &status, 1)  <--- BLOCKS until mount result arrives
>> +          |      |
>> +          |      +-- [fusermount3 performs mount and sends status byte]
>> +          |
>> +          +-- if (status != 0) return -1  <--- Mount failed
>> +          |
>> +          +-- return 0  <--- Mount succeeded
>> +
>> +
>> +Utility (util/fusermount.c):
>> +fusermount3 main() with --sync-init
>> +   |
>> +   +-- mount_fuse_sync_init()  [util/fusermount.c]
>> +          |
>> +          +-- mount_fuse_prepare()  [util/fusermount.c]
>> +          |      |
>> +          |      +-- open("/dev/fuse")
>> +          |      |
>> +          |      +-- check_perm()  [util/fusermount.c]
>> +          |      |
>> +          |      +-- return fd
>> +          |
>> +          +-- send_fd(socket, fd)  [util/fusermount.c]
>> +          |      |
>> +          |      +-- sendmsg(SCM_RIGHTS)
>> +          |
>> +          +-- wait_for_signal(socket)  [util/fusermount.c] <--- BLOCKS until library signals
>> +          |      |
>> +          |      +-- recv(socket, buf, 1)
>> +          |      |
>> +          |      +-- return 0
>> +          |
>> +          +-- mount_fuse_finish_fsmount()  [util/fusermount.c]
>> +          |      |
>> +          |      +-- fuse_kern_fsmount()  [lib/mount_fsmount.c]
>> +          |      |      |
>> +          |      |      +-- fsopen("fuse", FSOPEN_CLOEXEC)
>> +          |      |      |      |
>> +          |      |      |      +-- [kernel creates filesystem context]
>> +          |      |      |
>> +          |      |      +-- fsconfig(fsfd, SET_STRING, "source", ...)
>> +          |      |      +-- fsconfig(fsfd, SET_STRING, "fd", fd_value, ...)
>> +          |      |      +-- fsconfig(fsfd, ...) [apply mount options]
>> +          |      |      +-- fsconfig(fsfd, CMD_CREATE, ...)
>> +          |      |      |
>> +          |      |      +-- fsmount(fsfd, FSMOUNT_CLOEXEC, mount_attrs)
>> +          |      |      |      |
>> +          |      |      |      +-- [kernel sends FUSE_INIT here]
>> +          |      |      |      |
>> +          |      |      |      +-- [worker thread processes INIT]
>> +          |      |      |      |
>> +          |      |      |      +-- [fsmount returns mntfd]
>> +          |      |      |
>> +          |      |      +-- move_mount(mntfd, "", AT_FDCWD, target, ...)
>> +          |      |      |      |
>> +          |      |      |      +-- [attach mount to target directory]
>> +          |      |      |      |
>> +          |      |      |      +-- [no blocking - INIT already processed]
>> +          |      |      |
>> +          |      |      +-- add_mount()  [lib/mount_fsmount.c - update /etc/mtab]
>> +          |      |      |
>> +          |      |      +-- return 0 on success, -1 on failure
>> +          |      |
>> +          |      +-- if mount failed: return -1
>> +          |      +-- if mount succeeded: continue
>> +          |
>> +          +-- send_status_byte(socket)  [util/fusermount.c] <--- NEW: Send result to library
>> +          |      |
>> +          |      +-- status = (mount_result == 0) ? 0 : 1
>> +          |      +-- send(socket, &status, 1)
>> +          |      |
>> +          |      +-- return
>> +          |
>> +          +-- return 0
>> +
>> +
>> +Note: The new mount API (fsopen/fsconfig/fsmount/move_mount) is REQUIRED
>> +      for sync-init because fsmount() triggers FUSE_INIT before the mount
>> +      is attached. This allows the worker thread to process INIT before
>> +      move_mount() completes, preventing deadlock.
>> +      And also so we don't expose the directory tree to the mountns until we
>> +      know that FUSE_INIT didn't crash the server.
> 
> Question: Can libfuse call fuse_reply_err in response to an ->init call
> if the fuse server wants to fail a synchronous mount?  Right now it
> looks as if it always calls fuse_reply_ok, but I'm curious because that
> might be a more graceful way for a fuse server to fail than just
> terminating.

I guess so, see fs/fuse/dev.c fuse_request_end()

	if (test_bit(FR_ASYNC, &req->flags))
		req->args->end(fm, req->args, req->out.h.error);


> 
> (Granted the kernel still has to handle the fuse server blowing up
> unintentionally.)
> 
>> +
>> diff --git a/doc/README.mount b/doc/README.mount
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..526382ad8a5f6b405a7cb1927b79bacd6c2c2c5c
>> --- /dev/null
>> +++ b/doc/README.mount
>> @@ -0,0 +1,86 @@
>> +FUSE Mount API Flowcharts
>> +=========================
>> +
>> +Old Mount API
>> +-------------
>> +
>> +fuse_kern_mount()
>> +  |
>> +  +-- fuse_mount_sys()
>> +  |     +-- Try direct mount → mount() syscall
>> +  |     +-- On EPERM: fuse_mount_fusermount()
>> +  |           +-- socketpair()
>> +  |           +-- spawn fusermount3 (no --sync-init)
>> +  |           +-- fusermount3: open /dev/fuse, mount(), send fd
>> +  |           +-- receive_fd() → return fd
>> +  |
>> +  +-- Worker threads started AFTER mount
>> +  └─> FUSE_INIT asynchronous (queued in kernel)
>> +
>> +
>> +New Mount API - Privileged Mount
>> +---------------------------------
>> +
>> +fuse_session_mount_new_api()
>> +  |
>> +  +-- fuse_kern_mount_prepare() → open /dev/fuse → fd
>> +  |
>> +  +-- session_start_sync_init(se, fd)
>> +  |     +-- ioctl(fd, FUSE_DEV_IOC_SYNC_INIT)
>> +  |     +-- pthread_create(worker) → ready to process FUSE_INIT
>> +  |
>> +  +-- fuse_kern_fsmount_mo()
>> +  |     +-- fsopen/fsconfig/fsmount (BLOCKS until FUSE_INIT completes)
>> +  |     +-- Worker processes FUSE_INIT during fsmount()
>> +  |     +-- move_mount()
>> +  |
>> +  +-- session_wait_sync_init_completion(se) → pthread_join
>> +  └─> return fd
>> +
>> +
>> +New Mount API - EPERM Fallback (fusermount3 with sync-init)
>> +------------------------------------------------------------
>> +
>> +fuse_session_mount_new_api()
>> +  |
>> +  +-- fuse_kern_mount_prepare() → open /dev/fuse → fd1
>> +  |
>> +  +-- session_start_sync_init(se, fd1)
>> +  |     +-- ioctl(fd1, FUSE_DEV_IOC_SYNC_INIT)
>> +  |     +-- pthread_create(worker) → ready with fd1
>> +  |
>> +  +-- fuse_kern_fsmount_mo() → EPERM
>> +  |
>> +  +-- *** FALLBACK TO FUSERMOUNT3 WITH SYNC-INIT ***
>> +  |
>> +  +-- session_wait_sync_init_completion(se)
>> +  |     +-- pthread_cancel/join → terminate worker with wrong fd1
>> +  |
>> +  +-- close(fd1)
>> +  |
>> +  +-- fuse_mount_fusermount_sync_init()  [NEW]
>> +  |     +-- socketpair()
>> +  |     +-- spawn fusermount3 --sync-init
>> +  |     +-- fusermount3: open /dev/fuse → fd2, send fd2
>> +  |     +-- receive_fd() → fd2
>> +  |     +-- fusermount3 waits for signal
>> +  |     └─> return fd2, sock
>> +  |
>> +  +-- session_start_sync_init(se, fd2)
>> +  |     +-- ioctl(fd2, FUSE_DEV_IOC_SYNC_INIT)
>> +  |     +-- pthread_create(worker) → ready with fd2
>> +  |
>> +  +-- send_proceed_signal(sock)  [NEW]
>> +  |     +-- send(sock, "\0", 1) → signal fusermount3
>> +  |
>> +  +-- fusermount3: mount() (BLOCKS)
>> +  |     +-- Kernel sends FUSE_INIT to fd2
>> +  |     +-- Worker processes FUSE_INIT
>> +  |     +-- mount() returns
>> +  |
>> +  +-- close(sock)
>> +  |
>> +  +-- session_wait_sync_init_completion(se) → pthread_join
>> +  |
>> +  └─> return fd2
> 
> I'm not sure how useful it is to mention what's inside these functions,
> since one could read the code and I worry that the code will diverge
> very quickly.
> 
>> +
>> diff --git a/doc/README.sync-init b/doc/README.sync-init
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..44e47a2eef2c45026abaa19562537eef37f256b9
>> --- /dev/null
>> +++ b/doc/README.sync-init
>> @@ -0,0 +1,184 @@
>> +FUSE Synchronous vs Asynchronous FUSE_INIT
>> +============================================
>> +
>> +This document explains the difference between asynchronous and synchronous
>> +FUSE_INIT processing, and when each mode is used.
>> +
>> +
>> +Overview
>> +--------
>> +
>> +FUSE_INIT is the initial handshake between the kernel FUSE module and the
>> +userspace filesystem daemon. During this handshake, the kernel and daemon
>> +negotiate capabilities, protocol version, and various feature flags.
>> +
>> +Asynchronous FUSE_INIT (Traditional Behavior)
>> +----------------------------------------------
>> +
>> +In the traditional asynchronous mode:
>> +
>> +1. mount() syscall completes and returns to caller
>> +2. Filesystem appears mounted to the system
>> +3. FUSE daemon starts worker threads
>> +4. Worker threads process FUSE_INIT request
>> +5. Filesystem becomes fully operational
>> +
>> +Timeline:
>> +    mount() -----> returns
>> +                   |
>> +                   v
>> +            FUSE_INIT sent
>> +                   |
>> +                   v
>> +            daemon processes FUSE_INIT
>> +                   |
>> +                   v
>> +            filesystem ready
>> +
>> +Limitations:
>> +
>> +1. **No early requests**: The kernel cannot send requests (like getxattr)
>> +   during the mount() syscall. This breaks SELinux, which needs to query
>> +   extended attributes on the root inode immediately upon mounting.
>> +
>> +2. **Daemonization timing**: With the old fuse_daemonize() API, the daemon
>> +   must call it AFTER mount, because there's no way to report mount failures
>> +   to the parent process if daemonization happens first.
>> +
>> +3. **No custom root inode**: The root inode ID is hardcoded to FUSE_ROOT_ID (1)
>> +   because FUSE_INIT hasn't been processed yet when the mount completes.
>> +
>> +4. **Thread startup after mount**: io_uring threads and other worker threads
>> +   can only start after mount() returns, not before.
>> +
>> +
>> +Synchronous FUSE_INIT (New Behavior)
>> +-------------------------------------
>> +
>> +Kernel support: Linux kernel commit dfb84c330794 (v6.18+)
>> +libfuse support: libfuse 3.19+
>> +
>> +In synchronous mode:
>> +
>> +1. FUSE daemon opens /dev/fuse
>> +2. Daemon calls ioctl(fd, FUSE_DEV_IOC_SYNC_INIT)
>> +3. Daemon starts worker thread
>> +4. Daemon calls mount() syscall
>> +5. Kernel sends FUSE_INIT during mount() - mount() blocks
>> +6. Worker thread processes FUSE_INIT while mount() is blocked
>> +7. Worker thread may process additional requests (getxattr, etc.)
>> +8. mount() syscall completes and returns
>> +9. Filesystem is fully operational
>> +
>> +Timeline:
>> +    open /dev/fuse
>> +         |
>> +         v
>> +    ioctl(FUSE_DEV_IOC_SYNC_INIT)
>> +         |
>> +         v
>> +    start worker thread
>> +         |
>> +         v
>> +    mount() -----> blocks
>> +         |         |
>> +         |         v
>> +         |    FUSE_INIT sent
>> +         |         |
>> +         |         v
>> +         |    worker processes FUSE_INIT
>> +         |         |
>> +         |         v
>> +         |    (possible getxattr, etc.)
>> +         |         |
>> +         +-------> returns
>> +                   |
>> +                   v
>> +            filesystem ready
>> +
>> +Advantages:
>> +
>> +1. **SELinux support**: The kernel can send getxattr requests during mount()
>> +   to query security labels on the root inode.
>> +
>> +2. **Early daemonization**: The daemon can fork BEFORE mount using the new
>> +   fuse_daemonize_start()/signal() API, and report mount failures to the
>> +   parent process.
>> +
>> +3. **Custom root inode**: The daemon can specify a custom root inode ID
>> +   during FUSE_INIT, before mount() completes.
> 
> Where?  Or are you talking about this?
> https://lore.kernel.org/linux-fsdevel/177188735166.3936993.12658858435281080344.stgit@frogsfrogsfrogs/
> 
> but perhaps the root nodeid can be supplied in the reply from the
> synchronous FUSE_INIT?
> 
>> +
>> +4. **Thread startup before mount**: io_uring threads and worker threads
>> +   start before mount(), ensuring they're ready to handle requests.
>> +
>> +5. **Better error reporting**: Mount failures and initialization errors
>> +   can be properly reported to the parent process when using the new
>> +   daemonization API.
>> +
>> +
>> +When Synchronous FUSE_INIT is Used
>> +-----------------------------------
>> +
>> +libfuse automatically enables synchronous FUSE_INIT when:
>> +
>> +1. The application calls fuse_session_want_sync_init(), OR
>> +2. The new daemonization API is used (fuse_daemonize_start() was called)
>> +
>> +Synchronous FUSE_INIT requires:
>> +- Kernel support (commit dfb84c330794 or later)
>> +- Worker thread started before mount()
>> +- ioctl(FUSE_DEV_IOC_SYNC_INIT) succeeds
>> +
>> +If the kernel doesn't support synchronous FUSE_INIT, libfuse automatically
>> +falls back to asynchronous mode.
>> +
>> +
>> +Implementation Details
>> +----------------------
>> +
>> +The synchronous FUSE_INIT implementation uses a worker thread:
>> +
>> +- **session_sync_init_worker()**: Thread function that polls /dev/fuse
>> +  and processes FUSE_INIT and any subsequent requests until mount completes.
>> +
>> +- **session_start_sync_init()**: Creates the worker thread before mount().
>> +  Calls ioctl(FUSE_DEV_IOC_SYNC_INIT) to enable kernel support.
>> +
>> +- **session_wait_sync_init_completion()**: Waits for the worker thread
>> +  to complete after mount() returns. Checks for errors.
>> +
>> +The worker thread processes requests in a loop until se->terminate_mount_worker
>> +is set, which happens after mount() completes successfully.
> 
> Now that I've looked through this more carefully, I think it's all right
> to do this.
> 
>> +
>> +
>> +Compatibility
>> +-------------
>> +
>> +Synchronous FUSE_INIT is fully backward compatible:
>> +
>> +- Old kernels: ioctl returns ENOTTY, libfuse falls back to async mode
>> +- Old applications: Continue to work with async FUSE_INIT
>> +- New applications on old kernels: Graceful fallback to async mode
>> +- New applications on new kernels: Automatic sync mode when appropriate
>> +
>> +
>> +Example: Enabling Synchronous FUSE_INIT
>> +----------------------------------------
>> +
>> +Explicit request:
>> +    struct fuse_session *se = fuse_session_new(...);
>> +    fuse_session_want_sync_init(se);
>> +    fuse_session_mount(se, mountpoint);
>> +
>> +Automatic (with new daemonization API):
>> +    fuse_daemonize_start(0);  // Triggers sync init automatically
>> +    fuse_session_mount(se, mountpoint);
>> +
>> +
>> +See Also
>> +--------
>> +
>> +- doc/README.daemonize - New daemonization API documentation
>> +- doc/README.fusermount - Synchronous FUSE_INIT protocol with fusermount3
>> +- doc/README.mount - Mount implementation details
> 
> Thanks for splitting out the documentation updates.
> 
> --D
> 
>> +
>>
>> -- 
>> 2.43.0
>>
>>


  reply	other threads:[~2026-04-20  0:21 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 21:34 [PATCH v2 00/25] libfuse: Add support for synchronous init Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 01/25] ci-build: Add environment logging Bernd Schubert
2026-03-27  3:20   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 02/25] Add 'STRCPY' to the checkpatch ignore option Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 03/25] checkpatch.pl: Add _Atomic to $Attribute patttern Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 04/25] Add a new daemonize API Bernd Schubert
2026-03-27 22:06   ` Darrick J. Wong
2026-03-27 23:07     ` Bernd Schubert
2026-03-28  4:01       ` Darrick J. Wong
2026-03-30 17:45       ` Darrick J. Wong
2026-03-30 18:26         ` Bernd Schubert
2026-03-30 21:25           ` Darrick J. Wong
2026-03-30 17:55   ` Darrick J. Wong
2026-04-18 18:26     ` Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 05/25] Sync fuse_kernel.h with linux-6.18 Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 06/25] mount.c: Split fuse_mount_sys to prepare privileged sync FUSE_INIT Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 07/25] Add FUSE_MOUNT_FALLBACK_NEEDED define for -2 mount errors Bernd Schubert
2026-03-27  3:20   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 08/25] Refactor mount code / move common functions to mount_util.c Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 09/25] Use asprintf() for fuse_mnt_build_{source,type} Bernd Schubert
2026-03-27  3:24   ` Darrick J. Wong
2026-03-30 15:34     ` Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 10/25] lib/mount.c: Remove some BSD ifdefs Bernd Schubert
2026-03-27  3:28   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 11/25] Move 'struct mount_flags' to util.h Bernd Schubert
2026-03-30 18:11   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 12/25] conftest.py: Add more valgrind filter patterns Bernd Schubert
2026-03-30 18:16   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 13/25] Add support for the new linux mount API Bernd Schubert
2026-03-30 18:27   ` Darrick J. Wong
2026-04-19 17:45     ` Bernd Schubert
2026-04-20 15:48       ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 14/25] fuse mount: Support synchronous FUSE_INIT (privileged daemon) Bernd Schubert
2026-03-30 18:44   ` Darrick J. Wong
2026-04-19 22:36     ` Bernd Schubert
2026-04-20 15:53       ` Darrick J. Wong
2026-04-20 16:40         ` Bernd Schubert
2026-04-20 16:43           ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 15/25] Add fuse_session_set_debug() to enable debug output without foreground Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 16/25] Move more generic mount code to mount_util.{c,h} Bernd Schubert
2026-03-30 18:47   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 17/25] Split the fusermount do_mount function Bernd Schubert
2026-03-30 18:48   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 18/25] fusermout: Remove the large read check Bernd Schubert
2026-03-27  3:32   ` Darrick J. Wong
2026-03-30 15:26     ` Bernd Schubert
2026-03-30 17:57       ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 19/25] fusermount: Refactor extract_x_options Bernd Schubert
2026-03-26 21:34 ` [PATCH v2 20/25] Make fusermount work bidirectional for sync init Bernd Schubert
2026-03-30 19:03   ` Darrick J. Wong
2026-04-19 23:18     ` Bernd Schubert
2026-04-20 15:55       ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 21/25] New mount API: Filter out "user=" Bernd Schubert
2026-03-27  3:32   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 22/25] Add support for sync-init of unprivileged daemons Bernd Schubert
2026-03-31  0:54   ` Darrick J. Wong
2026-04-20  0:02     ` Bernd Schubert
2026-04-20 16:31       ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 23/25] Move fuse_mnt_build_{source,type} to mount_util.c Bernd Schubert
2026-03-30 19:04   ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 24/25] Add mount and daemonization README documents Bernd Schubert
2026-03-31  1:17   ` Darrick J. Wong
2026-04-20  0:21     ` Bernd Schubert [this message]
2026-04-20 16:39       ` Darrick J. Wong
2026-03-26 21:34 ` [PATCH v2 25/25] Add a background debug option to passthrough hp Bernd Schubert
2026-03-30 19:04   ` Darrick J. Wong
2026-04-07 12:04 ` fuse-devel list on kernel.org Amir Goldstein
2026-04-07 12:25   ` Bernd Schubert
2026-04-07 12:29     ` Amir Goldstein
2026-04-07 18:05       ` Bernd Schubert
2026-04-07 19:10         ` Darrick J. Wong
2026-04-08  8:21           ` Amir Goldstein
2026-04-13 12:23             ` Amir Goldstein
2026-04-13 12:36               ` Bernd Schubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aead083a-ff23-43b7-8fd5-ce543ea4d969@bsbernd.com \
    --to=bernd@bsbernd.com \
    --cc=djwong@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=kchen@ddn.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox