From: "Darrick J. Wong" <djwong@kernel.org>
To: bernd@bsbernd.com
Cc: neal@gompa.dev, fuse-devel@lists.linux.dev
Subject: Re: [PATCH 2/4] mount_service: mount via the shared fsmount helper
Date: Wed, 30 Sep 2026 08:16:54 -0700 [thread overview]
Message-ID: <20260930151654.GO6253@frogsfrogsfrogs> (raw)
In-Reply-To: <20260930-mount-service-use-mount-fsmount-v1-2-d585598896ee@bsbernd.com>
On Wed, Sep 30, 2026 at 03:44:34PM +0200, Bernd Schubert via B4 Relay wrote:
> From: Bernd Schubert <bernd@bsbernd.com>
>
> util/mount_service.c issued FSCONFIG_CMD_CREATE, fsmount() and
> move_mount() itself, with the same FSMOUNT_CLOEXEC and
> MOVE_MOUNT_*_EMPTY_PATH flags as lib/mount_fsmount.c. Both mount the
> same filesystem, so a flag changed in one copy silently diverges.
>
> mount_service.c also called the libc names fsconfig(), fsmount() and
> move_mount() directly. HAVE_NEW_MOUNT_API only checks that the headers
> declare these functions, not that libc exports them. On a system where
> NEED_NEW_MOUNT_API_SYSCALL_WRAPPERS is also set (glibc older than
> 2.36), lib/mount_fsmount.c works around the missing symbols through
> its fuse_-prefixed static inline wrappers, which mount_service.c had
> no access to; calling the bare libc names left it with a declaration
> to compile against but no symbol to link against.
>
> Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
> ---
> util/mount_service.c | 49 ++++++++++++-------------------------------------
> 1 file changed, 12 insertions(+), 37 deletions(-)
>
> diff --git a/util/mount_service.c b/util/mount_service.c
> index 0b3266309a8a..dcdc26df1db4 100644
> --- a/util/mount_service.c
> +++ b/util/mount_service.c
> @@ -28,11 +28,6 @@
> #include <sys/ioctl.h>
> #include <linux/fs.h>
>
> -#ifdef HAVE_NEW_MOUNT_API
> -#include <sys/mount.h>
> -#include <linux/mount.h>
> -#endif
> -
> #include "mount_util.h"
> #include "util.h"
> #include "fuse_i.h"
> @@ -1439,63 +1434,45 @@ static int mount_service_fsopen_mount(struct mount_service *mo,
> return FUSE_MOUNT_FALLBACK_NEEDED;
>
> error = -ret;
> - goto fail_fsconfig;
> + goto fail_mount;
> }
>
> snprintf(tmp, sizeof(tmp), "%i", mo->fusedevfd);
> ret = apply_fsconfig_opt_fd(mo->fsopenfd, tmp);
> if (ret < 0) {
> error = -ret;
> - goto fail_fsconfig;
> + goto fail_mount;
> }
>
> snprintf(tmp, sizeof(tmp), "%o", stbuf->st_mode & S_IFMT);
> ret = apply_fsconfig_opt_string(mo->fsopenfd, "rootmode", tmp);
> if (ret < 0) {
> error = -ret;
> - goto fail_fsconfig;
> + goto fail_mount;
> }
>
> snprintf(tmp, sizeof(tmp), "%u", getuid());
> ret = apply_fsconfig_opt_string(mo->fsopenfd, "user_id", tmp);
> if (ret < 0) {
> error = -ret;
> - goto fail_fsconfig;
> + goto fail_mount;
> }
>
> snprintf(tmp, sizeof(tmp), "%u", getgid());
> ret = apply_fsconfig_opt_string(mo->fsopenfd, "group_id", tmp);
> if (ret < 0) {
> error = -ret;
> - goto fail_fsconfig;
> - }
> -
> - ret = fsconfig(mo->fsopenfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
> - if (ret) {
> - error = errno;
> - fprintf(stderr, "%s: creating filesystem: %s\n",
> - mo->msgtag, strerror(error));
> - goto fail_fsconfig;
> - }
> -
> - mfd = fsmount(mo->fsopenfd, FSMOUNT_CLOEXEC, attr_flags);
> - if (mfd < 0) {
> - error = errno;
> - fprintf(stderr, "%s: fsmount: %s\n",
> - mo->msgtag, strerror(error));
> - goto fail_fsconfig;
> - }
> -
> - ret = move_mount(mfd, "", mo->mountfd, "",
> - MOVE_MOUNT_F_EMPTY_PATH | MOVE_MOUNT_T_EMPTY_PATH);
> - close(mfd);
> - if (ret) {
> - error = errno;
> - fprintf(stderr, "%s: move_mount: %s\n",
> - mo->msgtag, strerror(error));
> goto fail_mount;
> }
>
> + ret = fuse_fsmount_create_and_move(mo->fsopenfd, attr_flags,
> + mo->mountfd, NULL, &mfd);
> + if (ret < 0) {
> + error = -ret;
> + goto fail_mount;
> + }
> + close(mfd);
Slick :)
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> +
> /*
> * The mount succeeded, so we send a positive reply even if the mtab
> * update fails.
> @@ -1515,8 +1492,6 @@ static int mount_service_fsopen_mount(struct mount_service *mo,
> mo->mounted = true;
> return mount_service_send_reply(mo, 0);
>
> -fail_fsconfig:
> - log_fsconfig_kmsg(mo->fsopenfd);
> fail_mount:
> return mount_service_send_reply(mo, error);
> }
>
> --
> 2.53.0
>
>
>
next prev parent reply other threads:[~2026-09-30 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 13:44 [PATCH 0/4] libfuse: Avoid mount API code dup between mount-service and libfuse Bernd Schubert via B4 Relay
2026-09-30 13:44 ` [PATCH 1/4] mount_fsmount: split superblock creation and move_mount into a helper Bernd Schubert via B4 Relay
2026-09-30 15:13 ` Darrick J. Wong
2026-09-30 13:44 ` [PATCH 2/4] mount_service: mount via the shared fsmount helper Bernd Schubert via B4 Relay
2026-09-30 15:16 ` Darrick J. Wong [this message]
2026-09-30 13:44 ` [PATCH 3/4] mount_util: share the mtab flag-option builder Bernd Schubert via B4 Relay
2026-09-30 15:20 ` Darrick J. Wong
2026-09-30 13:44 ` [PATCH 4/4] mount/fuse_service: share the service socket helpers Bernd Schubert via B4 Relay
2026-09-30 15:23 ` Darrick J. Wong
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=20260930151654.GO6253@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bernd@bsbernd.com \
--cc=fuse-devel@lists.linux.dev \
--cc=neal@gompa.dev \
/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