From patchwork Thu Oct 16 19:39:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 5093941 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E11749F30B for ; Thu, 16 Oct 2014 19:39:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 117C6201F4 for ; Thu, 16 Oct 2014 19:39:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 22C8C201EF for ; Thu, 16 Oct 2014 19:39:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751347AbaJPTji (ORCPT ); Thu, 16 Oct 2014 15:39:38 -0400 Received: from mail-ie0-f176.google.com ([209.85.223.176]:65506 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751935AbaJPTjh (ORCPT ); Thu, 16 Oct 2014 15:39:37 -0400 Received: by mail-ie0-f176.google.com with SMTP id rp18so4189347iec.35 for ; Thu, 16 Oct 2014 12:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:from:to:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=CquXM7V1++F8WfKIw/14+9fWYpDyvCh3roPcHCuf5bg=; b=jifFtJRG1aCgspOiKAPTBDXf5wvZCkDVkGS+T1CCBqkR+RTvmoRsBvSsTYhWjng5+x ymMhXZbG2RHsT/Ss/ofVcD6lDuOBjL+THYsZj660W5emPp1zJgXEZzyzVBvendJUCH6o AJR2eWU096D/vxv5uF+LV//1hibOgcgxHq6s6XvQLbYRMhxFWldnHnYc+jtvorZU/8+l zQuFjeFqUGV61lrqt+cnzKE7YEpizAhSwqUPe1DgvXW0/ljiCdCIGOwWKrKOyIfPpZpV qKx+V2dMPfqcMIpvlS/QN7E9UGf+DEDnws5+fwAPMk02hOu3+jql5e0JetOy2bvxtxBR LHHQ== X-Received: by 10.42.80.143 with SMTP id v15mr6319650ick.54.1413488376908; Thu, 16 Oct 2014 12:39:36 -0700 (PDT) Received: from manet.1015granger.net ([2604:8800:100:81fc:82ee:73ff:fe43:d64f]) by mx.google.com with ESMTPSA id hi1sm1273190igb.18.2014.10.16.12.39.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 12:39:36 -0700 (PDT) Subject: [PATCH v1 10/16] NFS: Include transport protocol name in UCS client string From: Chuck Lever To: linux-nfs@vger.kernel.org Date: Thu, 16 Oct 2014 15:39:35 -0400 Message-ID: <20141016193935.13414.97081.stgit@manet.1015granger.net> In-Reply-To: <20141016192919.13414.3151.stgit@manet.1015granger.net> References: <20141016192919.13414.3151.stgit@manet.1015granger.net> User-Agent: StGit/0.17.1-3-g7d0f MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The nfs_match_client() function asserts that different nfs_client structures are used when mounting the same server with different transport protocols. For example, if a Linux client mounts the same server via NFSv3 with some UDP mounts and some TCP mounts, it will use only two transports and two nfs_client structures: one shared with all UDP mounts, and one shared with all TCP mounts. When a uniform client string is in use (NFSv4.1, or NFSv4.0 with the "migration" mount option), nfs_match_client() will ensure an nfs_client structure and separate transport is created for mounts with unique "proto=" settings (one for TCP and one for RDMA, currently). But EXCHANGE_ID sends exactly the same nfs_client_id4 string on both transports. The server then believes that the client is trunking over disparate transports, when it clearly is not. The open and lock state that will appear on each transport is disjoint. Now that NFSv4.1 over RDMA is supported, a user can mount the same server with NFSv4.1 over TCP and RDMA concurrently. The client will send an EXCHANGE_ID with the same client ID on both transports, and it will also send a CREATE_SESSION on both. To ensure the Linux client represents itself correctly to servers, add the transport protocol name to the uniform client string. Each transport instance should get its own client ID (and session) to prevent trunking. This doesn't appear to be a problem for NFSv4.0 without migration. It also wasn't a problem for NFSv4.1 when TCP was the only available transport. Signed-off-by: Chuck Lever --- fs/nfs/nfs4proc.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 6ca0c8e..a1243e7 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -4929,16 +4929,23 @@ nfs4_init_uniform_client_string(const struct nfs_client *clp, char *buf, size_t len) { const char *nodename = clp->cl_rpcclient->cl_nodename; + unsigned int result; + rcu_read_lock(); if (nfs4_client_id_uniquifier[0] != '\0') - return scnprintf(buf, len, "Linux NFSv%u.%u %s/%s", + result = scnprintf(buf, len, "Linux NFSv%u.%u %s/%s %s", clp->rpc_ops->version, clp->cl_minorversion, nfs4_client_id_uniquifier, - nodename); - return scnprintf(buf, len, "Linux NFSv%u.%u %s", + nodename, rpc_peeraddr2str(clp->cl_rpcclient, + RPC_DISPLAY_PROTO)); + else + result = scnprintf(buf, len, "Linux NFSv%u.%u %s %s", clp->rpc_ops->version, clp->cl_minorversion, - nodename); + nodename, rpc_peeraddr2str(clp->cl_rpcclient, + RPC_DISPLAY_PROTO)); + rcu_read_unlock(); + return result; } /*