Re: [PATCH] vfs: parse sloppy mount option in correct order

[Eric Sandeen <sandeen@sandeen.net>]

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;

-Eric