From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 6 12:46:40 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354AD16A417 for ; Mon, 6 Aug 2007 12:46:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id C480713C442 for ; Mon, 6 Aug 2007 12:46:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1II1Qc-0004tM-Nh; Mon, 06 Aug 2007 15:11:21 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l76CAxdB055103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 15:10:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l76CAxx6008786; Mon, 6 Aug 2007 15:10:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l76CAxPb008785; Mon, 6 Aug 2007 15:10:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Aug 2007 15:10:59 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20070806121059.GD2738@deviant.kiev.zoral.com.ua> References: <20070803192910.GA23699@carrot.studby.ntnu.no> <20070806111017.GA4170@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G2kvLHdEX2DcGdqq" Content-Disposition: inline In-Reply-To: <20070806111017.GA4170@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b72b012eade34d4806fecc225a7d7ed8 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1336 [August 3 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-hackers@freebsd.org, Ulf Lilleengen Subject: Re: VFS locking questions 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: Mon, 06 Aug 2007 12:46:40 -0000 --G2kvLHdEX2DcGdqq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 06, 2007 at 01:10:18PM +0200, Pawel Jakub Dawidek wrote: > On Fri, Aug 03, 2007 at 09:29:33PM +0200, Ulf Lilleengen wrote: > > Hi, > >=20 > > I have a couple of questions regarding VFS, since I'm trying to SMPify = the > > fdescfs code in an effort to get some experience with VFS and freebsd l= ocking... > >=20 > > What is really LK_INTERLOCK? When should it be used? When should one ac= quire it > > (with VI_LOCK i assume), and what are the "semantics"? =20 >=20 > Vnode internal lock (v_interlock, VI_LOCK()) is used to protect various > field in the vnode structure (those marked with 'i' letter in vnode.h). > You pass the LK_INTERLOCK flag to functions like lockmgr(), vn_lock(), > VOP_UNLOCK() when you already hold vnode's interlock. This way if one of > those functions needs vnode's interlock internally, it knows if you > already hold it or not (thus the function needs to acquire it on its > own). We could probably just use mtx_owned() inside those functions. >=20 > > Let's say I have a function that should return a locked vnode. I lock t= he > > hash-table with a regular mutex. Then, when I traverse the list, I chec= k if the > > entry is what I look for. If it is, I call VI_LOCK() on the vnode, use = vget to > > increment refcount, and then use vn_lock(vp, LK_EXCLUSIVE...) to lock t= he vnode > > before the function returns. Is this correct behaviour?=20 >=20 > Instead of doing what you suggest: >=20 > VI_LOCK(vp); > vget(vp, LK_INTERLOCK, td); > vn_lock(vp, LK_EXCLUSIVE, td); >=20 > You can simply call: >=20 > vget(vp, LK_EXCLUSIVE, td); >=20 > This is why: > - You haven't passed LK_INTERLOCK, so vget() will lock it by itself if > needed (it does need it). > - You passed LK_EXCLUSIVE, so vget() will return locked vnode. >=20 > > The LK_INTERLOCK bothers me a bit, because I'm not 100% sure on how it = works. >=20 > It probably mostly an optimization and probably protection before some > races, so you can call various functions with vnode's interlock already > held. You cannot sleep while holding mutex. So, if you hash is locked by mutex, you cannot sleep in lockmgr() waiting for vnode lock. The solution is vnode interlock. Basically, while still holding hash list mutex, you can do VI_LOCK(vp); vholdl(vp); mtx_unlock(hash mutex); error =3D vget(vp, LK_EXCLUSIVE|LK_INTERLOCK, td); if (error) XXX vdrop(vp); avoiding the race with vnode being reclaimed. --G2kvLHdEX2DcGdqq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD4DBQFGtw/RC3+MBN1Mb4gRAmwiAJiJKXr4yLptppI/9a6iE4X4rq9kAKDJWIAl BHB6NU8iCkh6UpH83d5Wig== =UuJY -----END PGP SIGNATURE----- --G2kvLHdEX2DcGdqq--