All of lore.kernel.org
 help / color / mirror / Atom feed
From: Spencer Baugh <sbaugh@catern.com>
To: David Howells <dhowells@redhat.com>, Miklos Szeredi <miklos@szeredi.hu>
Cc: inux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: FUSE no longer allows empty string for "source" with new mount API
Date: Wed, 06 Jan 2021 17:37:00 -0500	[thread overview]
Message-ID: <871rexvgj7.fsf@catern.com> (raw)


Hi,

Calling mount(2) and passing an empty string for the "source" parameter
when mounting a FUSE filesystem used to work.

However, it seems after the migration to the new mount API, passing an
empty string for "source" with mount(2) no longer works, since the new
mount API actually parses the "source" parameter and doesn't allow an
empty string. This breaks users of FUSE which don't go through libfuse,
so it seems like a userspace-visible regression.

I haven't bisected to confirm that it's specifically the new mount API
which is the problem, just seen that it works on some old kernels and
fails on some kernels after

commit c30da2e981a703c6b1d49911511f7ade8dac20be
Author: David Howells <dhowells@redhat.com>
Date:   Mon Mar 25 16:38:31 2019 +0000

    fuse: convert to use the new mount API

so apologies if the culprit turns out to be something else.

I'd try to fix it myself, but I'm not sure how to completely ignore a
parameter with the new mount API - I assume that with the new mount API,
we need to explicitly handle "source", so something like the below
simple patch won't work.

Thanks,
Spencer Baugh

---
1 file changed, 8 deletions(-)
fs/fuse/inode.c | 8 --------

modified   fs/fuse/inode.c
@@ -449,7 +449,6 @@ enum {
 };
 
 static const struct fs_parameter_spec fuse_fs_parameters[] = {
-	fsparam_string	("source",		OPT_SOURCE),
 	fsparam_u32	("fd",			OPT_FD),
 	fsparam_u32oct	("rootmode",		OPT_ROOTMODE),
 	fsparam_u32	("user_id",		OPT_USER_ID),
@@ -473,13 +472,6 @@ static int fuse_parse_param(struct fs_context *fc, struct fs_parameter *param)
 		return opt;
 
 	switch (opt) {
-	case OPT_SOURCE:
-		if (fc->source)
-			return invalfc(fc, "Multiple sources specified");
-		fc->source = param->string;
-		param->string = NULL;
-		break;
-
 	case OPT_SUBTYPE:
 		if (ctx->subtype)
 			return invalfc(fc, "Multiple subtypes specified");


                 reply	other threads:[~2021-01-06 22:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=871rexvgj7.fsf@catern.com \
    --to=sbaugh@catern.com \
    --cc=dhowells@redhat.com \
    --cc=inux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.