On Fri, 2020-01-17 at 15:12 +0000, David Howells wrote: > Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > > mount.nfs4 -o vers=4,nolock 192.168.1.10:/srv/nfs/odroidhc1 > > /new_root > > Okay, it looks like the mount command makes two attempts at mounting. > Firstly, it does this: > > > [ 22.938314] NFSOP 'source=192.168.1.10:/srv/nfs/odroidhc1' > > [ 22.942638] NFSOP 'nolock=(null)' > > [ 22.945772] NFSOP 'vers=4.2' > > [ 22.948660] NFSOP 'addr=192.168.1.10' > > [ 22.952350] NFSOP 'clientaddr=192.168.1.12' > > [ 22.956831] NFS4: Couldn't follow remote path > > Which accepts the "vers=4.2" parameter as there's no check that that > is > actually valid given the configuration, but then fails > later. Secondly, it > does this: > > > [ 22.971001] NFSOP 'source=192.168.1.10:/srv/nfs/odroidhc1' > > [ 22.975217] NFSOP 'nolock=(null)' > > [ 22.978444] NFSOP 'vers=4' > > [ 22.981265] NFSOP 'minorversion=1' > > [ 22.984513] NFS: Value for 'minorversion' out of range > > mount.nfs4: Numerical result out of range > > which fails because of the minorversion=1 specification, where the > kernel > config didn't enable NFS_V4_1. > > It looks like it ought to have failed prior to these patches in the > same way: > > case Opt_minorversion: > if (nfs_get_option_ul(args, &option)) > goto out_invalid_value; > if (option > NFS4_MAX_MINOR_VERSION) > goto out_invalid_value; > mnt->minorversion = option; > break; > It looks like someone changed the return value from the old EINVAL to something else? The "Numerical result out of range" message above suggests it has been changed to EOVERFLOW, which probably is not supported by 'mount'. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
