When a 'mount -o remount...' is issued, the mount program reads the current
mount options from /etc/mtab so that it can pass them to the helper program. On
newer distros where /etc/mtab is a symlink to /proc/mounts, this will result in
a call to nfs_show_mount_options(), which has the following snippet:
seq_printf(m, ",proto=%s",
rpc_peeraddr2str(nfss->client, RPC_DISPLAY_NETID));
which in most cases will result in the mount program passing 'proto=tcp' to the
mount.nfs4 program, which mount.nfs4 then passes in the data field of the mount
syscall.
nfs_remount() calls nfs_parse_mount_options(), where the NFS_MOUNT_TCP flag will
be set in the nfs_parsed_mount_data's flag field. But nfs_remount() then calls
nfs_compare_remount_data(), where we will fail the very first check:
static int
nfs_compare_remount_data(struct nfs_server *nfss,
struct nfs_parsed_mount_data *data)
{
if (data->flags != nfss->flags ||
...
return -EINVAL;
...
because NFS_MOUNT_TCP was never set in the nfs_server's flags field in the first
place.
As a result, the remount operation fails:
# mount -o remount,ro /mnt/t
mount.nfs4: an incorrect mount option was specified
The following patch corrects that issue by having nfs4_validate_mount_flags()
set the NFS_MOUNT_TCP flag when appropriate.
Scott Mayhew (1):
nfs: Ensure NFS_MOUNT_TCP is correctly set for v4 mounts
fs/nfs/super.c | 3 +++
1 file changed, 3 insertions(+)
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
