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.