From owner-freebsd-fs@FreeBSD.ORG Wed Oct 19 06:07:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88BDA106564A for ; Wed, 19 Oct 2011 06:07:21 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1C78FC0C for ; Wed, 19 Oct 2011 06:07:20 +0000 (UTC) X-AuditID: 1209190d-b7f726d0000008d1-a3-4e9e6918e402 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6F.7C.02257.8196E9E4; Wed, 19 Oct 2011 02:07:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p9J67Ko2008830; Wed, 19 Oct 2011 02:07:20 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9J67Ieh008769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 02:07:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p9J67IUA010311; Wed, 19 Oct 2011 02:07:18 -0400 (EDT) Date: Wed, 19 Oct 2011 02:07:17 -0400 (EDT) From: Benjamin Kaduk To: rmacklem@freebsd.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nriuROc/P4EwXv8Wxxz/ZLOb+3c/o wOQx49N8lgDGKC6blNSczLLUIn27BK6MB7eOMhc0i1ccvuzRwHiRp4uRg0NCwETi6BrVLkZO IFNM4sK99WxdjFwcQgL7GCUmHtvDCOFsYJSY/HcKO4RzgEli2d+9jCAtQgINjBLTjweB2CwC 2hIvjj9lArHZBFQkZr7ZyAZiiwhISJy8d4wZZBuzgJTEnbUVIKawgLHE1DYLkApeAXuJa0eX s4LYogI6Eqv3T2GBiAtKnJz5BMxmFrCU+Lf2F+sERv5ZSFKzkKQWMDKtYpRNya3SzU3MzClO TdYtTk7My0st0jXSy80s0UtNKd3ECAo0TkneHYzvDiodYhTgYFTi4d0hN89PiDWxrLgy9xCj JAeTkiivWgZQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv4TSgHG9KYmVValE+TEqag0VJnLdw h4OfkEB6YklqdmpqQWoRTFaGg0NJgnc2yFDBotT01Iq0zJwShDQTByfIcB6g4bEgNbzFBYm5 xZnpEPlTjIpSQKNBEgIgiYzSPLheWCJ4xSgO9IowbwJIFQ8wicB1vwIazAQ0+KjiXJDBJYkI KakGRkeH9d8+756/PX7nX5V/BSlFZ2a9mM6+ijVpgmjvcwl92/fpiavOVM2XPL8g++iRR+vX xSQEV7MZ3wxhXL32gl+hz9dA3mf3r/ctsVn1j+vjuQhhJ+nlSRM2VWwVzmsSmXZl71LJ5Haf 7eZC4VLbGupPP1+zv1Nr7e/v8+4E5JhtbzFN1Zuxk1eJpTgj0VCLuag4EQCPPn543wIAAA== Cc: freebsd-fs@freebsd.org Subject: lock status of dvp in lookup error return? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:07:21 -0000 Hi Rick, In tracking down a panic trying to recursively lock a vnode in openafs, I started questioning my behavior in the ISDOTDOT case, in particular whether to drop the dvp lock before the actual call over the network; this naturally led me to look at the NFS code as a reference. Unfortunately, this left me more confused than when I began ... sys/fs/nfs_clvnops.c, in nfs_lookup(): 1211 if (flags & ISDOTDOT) { 1212 ltype = NFSVOPISLOCKED(dvp); 1213 error = vfs_busy(mp, MBF_NOWAIT); 1214 if (error != 0) { 1215 vfs_ref(mp); 1216 NFSVOPUNLOCK(dvp, 0); 1217 error = vfs_busy(mp, 0); 1218 NFSVOPLOCK(dvp, ltype | LK_RETRY); If we fail to busy the mountpoint, drop the directory lock and try again, then relock dvp afterward. 1219 vfs_rel(mp); 1220 if (error == 0 && (dvp->v_iflag & VI_DOOMED)) { 1221 vfs_unbusy(mp); 1222 error = ENOENT; 1223 } 1224 if (error != 0) 1225 return (error); But if the second vfs_busy failed, or dvp is DOOMED, return with dvp locked. 1226 } 1227 NFSVOPUNLOCK(dvp, 0); But now we always unlock dvp. 1228 error = nfscl_nget(mp, dvp, nfhp, cnp, td, &np, NULL, 1229 cnp->cn_lkflags); The call to the network (?) 1230 if (error == 0) 1231 newvp = NFSTOV(np); 1232 vfs_unbusy(mp); 1233 if (newvp != dvp) 1234 NFSVOPLOCK(dvp, ltype | LK_RETRY); 1235 if (dvp->v_iflag & VI_DOOMED) { 1236 if (error == 0) { 1237 if (newvp == dvp) 1238 vrele(newvp); 1239 else 1240 vput(newvp); 1241 } 1242 error = ENOENT; 1243 } 1244 if (error != 0) 1245 return (error); And here if there was an error hearing from the network, we return with dvp still unlocked. 1246 if (attrflag) 1247 (void) nfscl_loadattrcache(&newvp, &nfsva, NULL, NULL, 1248 0, 1); So, I'm still confused about whether I should be unlocking dvp in the error case for ISDOTDOT (though presumably looking at other filesystems would help). This inconsistency in the NFS client looks like a bug at my current level of understanding -- what do you think? Thanks, Ben Kaduk