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
