On Thu, Aug 26, 2021 at 3:13 PM Eric Sandeen <sandeen@xxxxxxxxxxx> 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
>
> -Eric
>
