Re: [PATCH v2 22/25] Add support for sync-init of unprivileged daemons

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

On Mon, Apr 20, 2026 at 02:02:45AM +0200, Bernd Schubert wrote:
> 
> 
> On 3/31/26 02:54, Darrick J. Wong wrote:
> > On Thu, Mar 26, 2026 at 10:34:55PM +0100, Bernd Schubert wrote:
> >> From: Bernd Schubert <bschubert@ddn.com>
> >>
> >> This makes use of the bidirectional fusermount. Added is
> >> doc/README.mount, which explains the new bidirectional
> >> communication with fusermount.
> >>
> >> Signed-off-by: Bernd Schubert <bschubert@ddn.com>

<snip>

> >> + * On success, *sock_fd_out contains the socket fd for signaling fusermount3
> >> + */
> >> +int mount_fusermount_obtain_fd(const char *mountpoint, struct mount_opts *mo,
> >> +			       const char *opts, int *sock_fd_out,
> >> +			       pid_t *pid_out)
> >> +{
> >> +	int fds[2];
> >> +	pid_t pid;
> >> +	int res;
> >> +	char arg_fd_entry[ARG_FD_ENTRY_SIZE];
> >> +	posix_spawn_file_actions_t action;
> >> +	int fd, status;
> >> +
> >> +	(void)mo;
> >> +
> >> +	if (!mountpoint) {
> >> +		fuse_log(FUSE_LOG_ERR, "fuse: missing mountpoint parameter\n");
> >> +		return -1;
> >> +	}
> >> +
> >> +	res = socketpair(PF_UNIX, SOCK_STREAM, 0, fds);
> >> +	if (res == -1) {
> >> +		fuse_log(FUSE_LOG_ERR, "Running %s: socketpair() failed: %s\n",
> >> +			 FUSERMOUNT_PROG, strerror(errno));
> >> +		return -1;
> >> +	}
> >> +
> >> +	snprintf(arg_fd_entry, sizeof(arg_fd_entry), "%i", fds[0]);
> >> +	setenv(FUSE_COMMFD_ENV, arg_fd_entry, 1);
> >> +	snprintf(arg_fd_entry, sizeof(arg_fd_entry), "%i", fds[1]);
> >> +	setenv(FUSE_COMMFD2_ENV, arg_fd_entry, 1);
> >> +
> >> +	char const *const argv[] = {
> >> +		FUSERMOUNT_PROG,
> >> +		"--sync-init",
> >> +		"-o", opts ? opts : "",
> >> +		"--",
> >> +		mountpoint,
> >> +		NULL,
> >> +	};
> >> +
> >> +	posix_spawn_file_actions_init(&action);
> >> +	posix_spawn_file_actions_addclose(&action, fds[1]);
> >> +	status = fusermount_posix_spawn(&action, argv, &pid);
> >> +	posix_spawn_file_actions_destroy(&action);
> > 
> > Huh.  Would have been nice to have known about posix_spawn when I was
> > writing xfs_healer.
> 
> Could be still updated to that?

Yeah, it's possible.

> > 
> >> +
> >> +	if (status != 0) {
> >> +		close(fds[0]);
> >> +		close(fds[1]);
> >> +		return -1;
> >> +	}
> >> +
> >> +	close(fds[0]);
> >> +
> >> +	fd = receive_fd(fds[1]);
> >> +	if (fd < 0) {
> >> +		close(fds[1]);
> >> +		waitpid(pid, NULL, 0);
> >> +		return -1;
> >> +	}
> >> +
> >> +	fcntl(fd, F_SETFD, FD_CLOEXEC);
> >> +
> >> +	/* Return socket fd for later signaling */
> >> +	*sock_fd_out = fds[1];
> >> +	*pid_out = pid;
> >> +
> >> +	return fd;
> >> +}
> >> +
> >> +/*
> >> + * Send proceed signal to fusermount3 and wait for mount result
> >> + * Returns: 0 on success, -1 on failure
> >> + */
> >> +int fuse_fusermount_proceed_mnt(int sock_fd)
> >> +{
> >> +	char buf = '\0';
> >> +	ssize_t res;
> >> +
> >> +	/* Send proceed signal */
> >> +	do {
> >> +		res = send(sock_fd, &buf, 1, 0);
> >> +	} while (res == -1 && errno == EINTR);
> > 
> > Hrmm, I probably need to wrap the sendmsg/recvmsg calls in my own
> > patches to do this loop, don't I?

Nope.  Sequential packet sockets preserve boundaries between records
sent with MSG_EOR, and reads are required to provide a buffer large
enough to read the entire record.  Undersized read buffers result in the
rest of the record being dropped silently.

IOWs, there's no possibility of a short read or a short write.  But
perhaps I should be checking SO_SNDBUF (aka the maximum record size).

> I guess so, I will try to eventually look into your series later. Go
> painfully late (or early) to update code with all your review comments
> (and with family couldn't work through entirely in peace...).

<nod> I'll do a new posting to the new list before I depart for
LinuxFest on Thursday.

--D