NFS: Fix security flavor negotiation with legacy binary mounts
Darrick J. Wong <darrick.wong@oracle.com> reports: > I have a kvm-based testing setup that netboots VMs over NFS, the > client end of which seems to have broken somehow in 3.10-rc1. The > server's exports file looks like this: > > /storage/mtr/x64 192.168.122.0/24(ro,sync,no_root_squash,no_subtree_check) > > On the client end (inside the VM), the initrd runs the following > command to try to mount the rootfs over NFS: > > # mount -o nolock -o ro -o retrans=10 192.168.122.1:/storage/mtr/x64/ /root > > (Note: This is the busybox mount command.) > > The mount fails with -EINVAL. Commit 4580a92d "NFS: Use server-recommended security flavor by default (NFSv3)" introduced a behavior regression for NFS mounts done via a legacy binary mount(2) call. Ensure that a default security flavor is specified for legacy binary mount requests, since they do not invoke nfs_select_flavor() in the kernel. Busybox uses klibc's nfsmount command, which performs NFS mounts using the legacy binary mount data format. /sbin/mount.nfs is not affected by this regression. Reported-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: Weston Andros Adamson <dros@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Showing
Please register or sign in to comment