From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 3 19:30:06 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 0398E16A417 for ; Fri, 3 Aug 2007 19:30:06 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from decibel.pvv.ntnu.no (unknown [IPv6:2001:700:300:1900:2e0:81ff:fe2d:e9b2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3AA13C467 for ; Fri, 3 Aug 2007 19:30:05 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from tvilling.pvv.ntnu.no ([129.241.210.198] helo=carrot.studby.ntnu.no ident=lulf) by decibel.pvv.ntnu.no with esmtp (Exim 4.60) (envelope-from ) id 1IH2qZ-0003KK-Sp for freebsd-hackers@freebsd.org; Fri, 03 Aug 2007 21:30:04 +0200 Date: Fri, 3 Aug 2007 21:29:33 +0200 From: Ulf Lilleengen To: freebsd-hackers@freebsd.org Message-ID: <20070803192910.GA23699@carrot.studby.ntnu.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: 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: Fri, 03 Aug 2007 19:30:06 -0000 Hi, 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 locking... What is really LK_INTERLOCK? When should it be used? When should one acquire it (with VI_LOCK i assume), and what are the "semantics"? Let's say I have a function that should return a locked vnode. I lock the hash-table with a regular mutex. Then, when I traverse the list, I check 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 the vnode before the function returns. Is this correct behaviour? The LK_INTERLOCK bothers me a bit, because I'm not 100% sure on how it works. -- Ulf Lilleengen