From owner-svn-src-stable-10@FreeBSD.ORG Wed Dec 11 00:39:56 2013 Return-Path: Delivered-To: svn-src-stable-10@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7C8E2AF; Wed, 11 Dec 2013 00:39:56 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9230C1FBD; Wed, 11 Dec 2013 00:39:56 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id rBB0duJb098268; Wed, 11 Dec 2013 00:39:56 GMT (envelope-from rmacklem@svn.freebsd.org) Received: (from rmacklem@localhost) by svn.freebsd.org (8.14.7/8.14.7/Submit) id rBB0dulK098266; Wed, 11 Dec 2013 00:39:56 GMT (envelope-from rmacklem@svn.freebsd.org) Message-Id: <201312110039.rBB0dulK098266@svn.freebsd.org> From: Rick Macklem Date: Wed, 11 Dec 2013 00:39:56 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r259207 - stable/10/sys/fs/nfs X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:39:56 -0000 Author: rmacklem Date: Wed Dec 11 00:39:56 2013 New Revision: 259207 URL: http://svnweb.freebsd.org/changeset/base/259207 Log: MFC: r257598 During code inspection, I spotted that there was a code path where CLNT_CONTROL() would be called on "client" after it was released via CLNT_RELEASE(). It was unlikely that this code path gets executed and I have not heard of any problem report caused by this bug. This patch fixes the code so that this cannot happen. Modified: stable/10/sys/fs/nfs/nfs_commonkrpc.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/fs/nfs/nfs_commonkrpc.c ============================================================================== --- stable/10/sys/fs/nfs/nfs_commonkrpc.c Wed Dec 11 00:17:13 2013 (r259206) +++ stable/10/sys/fs/nfs/nfs_commonkrpc.c Wed Dec 11 00:39:56 2013 (r259207) @@ -336,24 +336,25 @@ newnfs_connect(struct nfsmount *nmp, str mtx_lock(&nrp->nr_mtx); if (nrp->nr_client != NULL) { + mtx_unlock(&nrp->nr_mtx); /* * Someone else already connected. */ CLNT_RELEASE(client); } else { nrp->nr_client = client; + /* + * Protocols that do not require connections may be optionally + * left unconnected for servers that reply from a port other + * than NFS_PORT. + */ + if (nmp == NULL || (nmp->nm_flag & NFSMNT_NOCONN) == 0) { + mtx_unlock(&nrp->nr_mtx); + CLNT_CONTROL(client, CLSET_CONNECT, &one); + } else + mtx_unlock(&nrp->nr_mtx); } - /* - * Protocols that do not require connections may be optionally left - * unconnected for servers that reply from a port other than NFS_PORT. - */ - if (nmp == NULL || (nmp->nm_flag & NFSMNT_NOCONN) == 0) { - mtx_unlock(&nrp->nr_mtx); - CLNT_CONTROL(client, CLSET_CONNECT, &one); - } else { - mtx_unlock(&nrp->nr_mtx); - } /* Restore current thread's credentials. */ td->td_ucred = origcred;