From: David Wysochanski <dwysocha@redhat.com>
To: Roberto Bergantinos Corpas <rbergant@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Matthew Wilcox <willy@infradead.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] vfs: parse sloppy mount option in correct order
Date: Thu, 23 Sep 2021 08:28:23 -0400 [thread overview]
Message-ID: <CALF+zOmuj2VJn=g-HwB8mbEPLtKcUC29LxLx4Vh2a_cjYw5A6A@mail.gmail.com> (raw)
In-Reply-To: <CACWnjLxtQOcpLGES1bX1cN8E4PYSx-EVk0=akMUss1pXuk1Q7A@mail.gmail.com>
On Thu, Aug 26, 2021 at 9:32 AM Roberto Bergantinos Corpas
<rbergant@redhat.com> wrote:
>
> On Thu, Aug 26, 2021 at 3:13 PM Eric Sandeen <sandeen@sandeen.net> wrote:
> >
> > On 8/26/21 7:46 AM, Matthew Wilcox wrote:
> > > On Wed, Jul 21, 2021 at 01:30:57PM +0200, Roberto Bergantinos Corpas wrote:
> > >> With addition of fs_context support, options string is parsed
> > >> sequentially, if 'sloppy' option is not leftmost one, we may
> > >> return ENOPARAM to userland if a non-valid option preceeds sloopy
> > >> and mount will fail :
> > >>
> > >> host# mount -o quota,sloppy 172.23.1.225:/share /mnt
> > >> mount.nfs: an incorrect mount option was specified
> > >> host# mount -o sloppy,quota 172.23.1.225:/share /mnt
> > >
> > > It isn't clear to me that this is incorrect behaviour. Perhaps the user
> > > actually wants the options to the left parsed strictly and the options
> > > to the right parsed sloppily?
> >
> > I don't think mount options have ever been order-dependent, at least not
> > intentionally so, have they?
> >
> > And what matters most here is surely "how did it work before the mount
> > API change?"
> >> And it seems to me that previously, invalid options were noted, and whether the
> > mount would fail was left to the end, depending on whether sloppy was seen
> > anywhere in the mount options string. This is the old option parsing:
> >
> > while ((p = strsep(&raw, ",")) != NULL) {
> > ...
> > switch (token) {
> > ...
> > case Opt_sloppy:
> > sloppy = 1;
> > dfprintk(MOUNT, "NFS: relaxing parsing rules\n");
> > break;
> > ...
> > default:
> > invalid_option = 1;
> > dfprintk(MOUNT, "NFS: unrecognized mount option "
> > "'%s'\n", p);
> > }
> > }
> >
> > if (!sloppy && invalid_option)
> > return 0;
>
> Agree, that's my main point. I think that breaks from previous
> behaviour and indeed causes issues on the field.
> My understanding too is that there's no order-dependency.
>
> roberto
>
Hi Roberto, Eric and David H, this seems to have stalled. What are
the next steps here?
Roberto, it sounded like David H was suggesting maybe an alternative
approach. Did you look into that?
Then there was a discussion about whether this change was intended
behavior or not, and the main point made was it was a change in
behavior, which I don't think was intended. I guess one could make
the argument order was never guaranteed, but then why make behavior
order dependent now if it was not intentional kernel change? I agree
if possible we should retain the order independent behavior in the
kernel.
next prev parent reply other threads:[~2021-09-23 12:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 11:30 [PATCH] vfs: parse sloppy mount option in correct order Roberto Bergantinos Corpas
2021-08-26 12:29 ` David Howells
2022-01-27 14:42 ` Roberto Bergantinos Corpas
2021-08-26 12:46 ` Matthew Wilcox
2021-08-26 13:05 ` Eric Sandeen
2021-08-26 13:32 ` Roberto Bergantinos Corpas
2021-09-23 12:28 ` David Wysochanski [this message]
2021-09-23 14:13 ` Roberto Bergantinos Corpas
2022-09-28 1:09 Ian Kent
2023-01-27 11:13 ` Jeff Layton
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='CALF+zOmuj2VJn=g-HwB8mbEPLtKcUC29LxLx4Vh2a_cjYw5A6A@mail.gmail.com' \
--to=dwysocha@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rbergant@redhat.com \
--cc=sandeen@sandeen.net \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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).