From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 3 14:46:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F24816A420 for ; Fri, 3 Feb 2006 14:46:48 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFE243D46 for ; Fri, 3 Feb 2006 14:46:47 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: by uproxy.gmail.com with SMTP id j3so302771ugf for ; Fri, 03 Feb 2006 06:46:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EepYFhBwCknq2FJXYEm2F48v1PpnBEc6yprsmqPNjCnL/f5kF5O63Y4cXqziL0s0sFByxhz6RDYKfQm8tt3q7G+IAtw21ds4dQ+Dt+9Lc8SShIJY1ODiVDxgKiKp03GtSJNipt571HJmd7KExCB4Qj9fUBvuOmjg1j6bjgOmaxU= Received: by 10.48.217.10 with SMTP id p10mr530923nfg; Fri, 03 Feb 2006 06:40:34 -0800 (PST) Received: by 10.48.230.8 with HTTP; Fri, 3 Feb 2006 06:40:34 -0800 (PST) Message-ID: Date: Fri, 3 Feb 2006 16:40:34 +0200 From: Kostik Belousov To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [possible patch] fdescfs vop_lookup and parent vnode locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 14:46:48 -0000 Is it correct that filesystem-specific vop_lookup is expected to take the directory vnode (dvp) locked, and shall return with dvp locked ? vnode_if.src specifies this behaviour as dependent on the flags in the cnp arguments. My reading of the sources suggest that the statement in the firs= t sentence is true, and note from vnode_if.src applies to sys/kern/vfs_lookup.c:lookup() procedure itself. If it is true, the fdescfs break this rule, dropping the lock on the dvp. S= ee sys/fs/fdescfs/fdesc_vnops.c, line 196. As result, having fdescfs mounted, most accesses to files on it cause warning from the lockmgr, lockmgr: thread XXX unlocking unheld lock I did some testing with the following patch Index: sys/fs/fdescfs/fdesc_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/fs/fdescfs/fdesc_vnops.c,v retrieving revision 1.100 diff -u -r1.100 fdesc_vnops.c --- sys/fs/fdescfs/fdesc_vnops.c=0910 Aug 2005 07:08:14 -0000=091.100 +++ sys/fs/fdescfs/fdesc_vnops.c=093 Feb 2006 14:35:11 -0000 @@ -193,11 +193,9 @@ =09=09goto bad; =09} -=09VOP_UNLOCK(dvp, 0, td); =09if (cnp->cn_namelen =3D=3D 1 && *pname =3D=3D '.') { =09=09*vpp =3D dvp; =09=09VREF(dvp); -=09=09vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY, td); =09=09return (0); =09} @@ -228,12 +226,12 @@ =09if (error) =09=09goto bad; =09VTOFDESC(fvp)->fd_fd =3D fd; -=09vn_lock(fvp, LK_EXCLUSIVE | LK_RETRY, td); +=09if (fvp !=3D dvp) +=09=09vn_lock(fvp, LK_EXCLUSIVE | LK_RETRY, td); =09*vpp =3D fvp; =09return (0); bad: -=09vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY, td); =09*vpp =3D NULL; =09return (error); } and do not see the warnings anymore. The system does not deadlock. What do you think about the problem ? Best regards, Kostik Belousov