linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	 Eric Sandeen <sandeen@redhat.com>
Cc: linux-renesas-soc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	 David Howells <dhowells@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] debugfs: ignore auto and noauto options if given
Date: Fri, 24 May 2024 15:55:10 +0200	[thread overview]
Message-ID: <20240524-glasfaser-gerede-fdff887f8ae2@brauner> (raw)
In-Reply-To: <20240522083851.37668-1-wsa+renesas@sang-engineering.com>

On Wed, May 22, 2024 at 10:38:51AM +0200, Wolfram Sang wrote:
> The 'noauto' and 'auto' options were missed when migrating to the new
> mount API. As a result, users with these in their fstab mount options
> are now unable to mount debugfs filesystems, as they'll receive an
> "Unknown parameter" error.
> 
> This restores the old behaviour of ignoring noauto and auto if they're
> given.
> 
> Fixes: a20971c18752 ("vfs: Convert debugfs to use the new mount API")
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
> 
> With current top-of-tree, debugfs remained empty on my boards triggering
> the message "debugfs: Unknown parameter 'auto'". I applied a similar fix
> which CIFS got and largely reused the commit message from 19d51588125f
> ("cifs: ignore auto and noauto options if given").
> 
> Given the comment in debugfs_parse_param(), I am not sure if this patch
> is a complete fix or if there are more options to be ignored. This patch
> makes it work for me(tm), however.
> 
> From my light research, tracefs (which was converted to new mount API
> together with debugfs) doesn't need the same fixing. But I am not
> super-sure about that.

Afaict, the "auto" option has either never existent or it was removed before
the new mount api conversion time ago for debugfs. In any case, the root of the
issue is that we used to ignore unknown mount options in the old mount api so
you could pass anything that you would've wanted in there:

/*
 * We might like to report bad mount options here;
 * but traditionally debugfs has ignored all mount options
 */

So there's two ways to fix this:

(1) We continue ignoring mount options completely when they're coming
    from the new mount api.
(2) We continue ignoring mount options toto caelo.

The advantage of (1) is that we gain the liberty to report errors to
users on unknown mount options in the future but it will break on
mount(8) from util-linux that relies on the new mount api by default. So
I think what we need is (2) so something like:

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index dc51df0b118d..713b6f76e75d 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -107,8 +107,16 @@ static int debugfs_parse_param(struct fs_context *fc, struct fs_parameter *param
        int opt;

        opt = fs_parse(fc, debugfs_param_specs, param, &result);
-       if (opt < 0)
+       if (opt < 0) {
+               /*
+                * We might like to report bad mount options here; but
+                * traditionally debugfs has ignored all mount options
+                */
+               if (opt == -ENOPARAM)
+                       return 0;
+
                return opt;
+       }

        switch (opt) {
        case Opt_uid:


Does that fix it for you?

  reply	other threads:[~2024-05-24 13:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22  8:38 [PATCH] debugfs: ignore auto and noauto options if given Wolfram Sang
2024-05-24 13:55 ` Christian Brauner [this message]
2024-05-27 10:06   ` Wolfram Sang
2024-05-27 10:23     ` Geert Uytterhoeven
2024-05-27 12:19     ` Christian Brauner
2024-06-03  7:24       ` Wolfram Sang
2024-06-03 13:31         ` Christian Brauner
2024-06-03 14:17           ` Eric Sandeen
2024-06-03 14:33             ` Christian Brauner
2024-06-03 15:13               ` Eric Sandeen
2024-06-05 15:33                 ` Christian Brauner
2024-06-03 19:52             ` Wolfram Sang
2024-05-29 20:43   ` Eric Sandeen
2024-05-29 22:05     ` Wolfram Sang
2024-05-29 22:33       ` Eric Sandeen

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=20240524-glasfaser-gerede-fdff887f8ae2@brauner \
    --to=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sandeen@redhat.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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;
as well as URLs for NNTP newsgroup(s).