From owner-svn-src-stable-9@FreeBSD.ORG Tue Dec 10 22:04:00 2013 Return-Path: Delivered-To: svn-src-stable-9@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 274564E3; Tue, 10 Dec 2013 22:04:00 +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 126DC14AB; Tue, 10 Dec 2013 22:04:00 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id rBAM3xa9041732; Tue, 10 Dec 2013 22:03:59 GMT (envelope-from rmacklem@svn.freebsd.org) Received: (from rmacklem@localhost) by svn.freebsd.org (8.14.7/8.14.7/Submit) id rBAM3xfx041731; Tue, 10 Dec 2013 22:03:59 GMT (envelope-from rmacklem@svn.freebsd.org) Message-Id: <201312102203.rBAM3xfx041731@svn.freebsd.org> From: Rick Macklem Date: Tue, 10 Dec 2013 22:03:59 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-9@freebsd.org Subject: svn commit: r259201 - stable/9/sys/fs/nfs X-SVN-Group: stable-9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable-9@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for only the 9-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:04:00 -0000 Author: rmacklem Date: Tue Dec 10 22:03:59 2013 New Revision: 259201 URL: http://svnweb.freebsd.org/changeset/base/259201 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/9/sys/fs/nfs/nfs_commonkrpc.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/fs/ (props changed) Modified: stable/9/sys/fs/nfs/nfs_commonkrpc.c ============================================================================== --- stable/9/sys/fs/nfs/nfs_commonkrpc.c Tue Dec 10 21:15:18 2013 (r259200) +++ stable/9/sys/fs/nfs/nfs_commonkrpc.c Tue Dec 10 22:03:59 2013 (r259201) @@ -316,24 +316,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;