Linux filesystem development
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Eric Sandeen <sandeen@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	 Steven Rostedt <rostedt@goodmis.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 "Rafael J. Wysocki" <rafael@kernel.org>,
	Bill O'Donnell <billodo@redhat.com>,
	 David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 1/2] vfs: Convert debugfs to use the new mount API
Date: Wed, 6 Mar 2024 13:17:38 +0100	[thread overview]
Message-ID: <20240306-alimente-tierwelt-01d46f2b9de7@brauner> (raw)
In-Reply-To: <CAJfpeguCKgMPBbD_ESD+Voxq5ChS9nGQFdYrA4+YWBz17yFADA@mail.gmail.com>

On Wed, Mar 06, 2024 at 01:13:05PM +0100, Miklos Szeredi wrote:
> On Wed, 6 Mar 2024 at 11:57, Christian Brauner <brauner@kernel.org> wrote:
> 
> > There's a tiny wrinkle though. We currently have no way of letting
> > userspace know whether a filesystem supports the new mount API or not
> > (see that mount option probing systemd does we recently discussed). So
> > if say mount(8) remounts debugfs with mount options that were ignored in
> > the old mount api that are now rejected in the new mount api users now
> > see failures they didn't see before.
> >
> > For the user it's completely intransparent why that failure happens. For
> > them nothing changed from util-linux's perspective. So really, we should
> > probably continue to ignore old mount options for backward compatibility.
> 
> The reject behavior could be made conditional on e.g. an fsopen() flag.

and fspick() which I think is more relevant.

> 
> I.e. FSOPEN_REJECT_UNKNOWN would make unknown options be always
> rejected.  Without this flag fsconfig(2) would behave identically
> before/after the conversion.

Yeah, that would work. That would only make sense if we make all
filesystems reject unknown mount options by default when they're
switched to the new mount api imho. When we recognize the request comes
from the old mount api fc->oldapi we continue ignoring as we did before.
If it comes from the new mount api we reject unless
FSOPEN/FSPICK_REJECT_UKNOWN was specified.

  reply	other threads:[~2024-03-06 12:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05 23:07 [PATCH 0/2] vfs: convert debugfs & tracefs to the new mount API Eric Sandeen
2024-03-05 23:08 ` [PATCH 1/2] vfs: Convert debugfs to use " Eric Sandeen
2024-03-06 10:50   ` Christian Brauner
2024-03-06 12:13     ` Miklos Szeredi
2024-03-06 12:17       ` Christian Brauner [this message]
2024-03-06 16:35         ` Eric Sandeen
2024-03-07 12:04           ` Christian Brauner
2024-03-08 14:54             ` Miklos Szeredi
2024-05-30 14:21     ` Eric Sandeen
2024-03-07 21:10   ` Greg Kroah-Hartman
2024-03-05 23:09 ` [PATCH 2/2] vfs: Convert tracefs " Eric Sandeen
2024-03-06 21:44   ` Steven Rostedt
2024-03-06 10:57 ` [PATCH 0/2] vfs: convert debugfs & tracefs to " Christian Brauner
2024-03-12 14:35 ` Christian Brauner

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=20240306-alimente-tierwelt-01d46f2b9de7@brauner \
    --to=brauner@kernel.org \
    --cc=billodo@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sandeen@redhat.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