From owner-svn-src-stable@freebsd.org Sat Jul 15 19:43:03 2017 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE2C7B7AB12; Sat, 15 Jul 2017 19:43:03 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F503828BA; Sat, 15 Jul 2017 19:43:03 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v6FJh2mh026736; Sat, 15 Jul 2017 19:43:02 GMT (envelope-from rmacklem@FreeBSD.org) Received: (from rmacklem@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v6FJh2nH026735; Sat, 15 Jul 2017 19:43:02 GMT (envelope-from rmacklem@FreeBSD.org) Message-Id: <201707151943.v6FJh2nH026735@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rmacklem set sender to rmacklem@FreeBSD.org using -f From: Rick Macklem Date: Sat, 15 Jul 2017 19:43:02 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: svn commit: r321032 - stable/11/sys/fs/nfsclient X-SVN-Group: stable-11 X-SVN-Commit-Author: rmacklem X-SVN-Commit-Paths: stable/11/sys/fs/nfsclient X-SVN-Commit-Revision: 321032 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:43:04 -0000 Author: rmacklem Date: Sat Jul 15 19:43:02 2017 New Revision: 321032 URL: https://svnweb.freebsd.org/changeset/base/321032 Log: MFC: r320458 Fix an NFSv3 client case that probably never happens. If an NFSv3 server were to reply with weak cache consistency attributes, but not post operation attributes, the client would use garbage attributes from memory. This was spotted during work on the code for the NFSv4.1 client. I have never seen evidence that this happens and it wouldn't make sense for an NFSv3 server to do this, so this patch is basically "theoretical", but does fix the problem if a server were to do the above. Modified: stable/11/sys/fs/nfsclient/nfs_clport.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/fs/nfsclient/nfs_clport.c ============================================================================== --- stable/11/sys/fs/nfsclient/nfs_clport.c Sat Jul 15 19:24:54 2017 (r321031) +++ stable/11/sys/fs/nfsclient/nfs_clport.c Sat Jul 15 19:43:02 2017 (r321032) @@ -743,6 +743,8 @@ nfscl_wcc_data(struct nfsrv_descript *nd, struct vnode } } error = nfscl_postop_attr(nd, nap, flagp, stuff); + if (wccflagp != NULL && *flagp == 0) + *wccflagp = 0; } else if ((nd->nd_flag & (ND_NOMOREDATA | ND_NFSV4 | ND_V4WCCATTR)) == (ND_NFSV4 | ND_V4WCCATTR)) { error = nfsv4_loadattr(nd, NULL, &nfsva, NULL,