From owner-freebsd-fs@FreeBSD.ORG Sun Feb 26 17:06:29 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90AA216A420 for ; Sun, 26 Feb 2006 17:06:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DFD43D6E for ; Sun, 26 Feb 2006 17:06:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k1QH6OZZ033087; Sun, 26 Feb 2006 10:06:24 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4401E010.7070804@samsco.org> Date: Sun, 26 Feb 2006 10:06:24 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wei Lei References: <36fee7420602250625h7271d694i7bfc9e69eda8ade7@mail.gmail.com> In-Reply-To: <36fee7420602250625h7271d694i7bfc9e69eda8ade7@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, Manish Rai Jain Subject: Re: Doubt about ntfs code: lockmgr with LK_INTERLOCK flag 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: Sun, 26 Feb 2006 17:06:29 -0000 Wei Lei wrote: > Hi list, > > Nice to be here =) > > I am new here so just hope my first post doesn't mismatch the topic. > > I have a doubt when understanding the ntfs code with freebsd 5.4: > ntfs_subr.c, function ntfs_ntget(). > I understand that lockmgr() here is trying to get an exclusive lock and > release the mutex ip->i_interlock, > so that the protection can expand from use_count to the whole ntnode. > > But what's the significance of having such a mechanism? What could possibly > happen if I do a > mtx_unlock first then acquire the exclusive lock? > Doing a mtx_unlock() could trigger your thread to get preempted by a higher priority thread that could then come in and modify the i_usecount field. Scott