From owner-freebsd-current@FreeBSD.ORG Wed Jun 4 05:26:06 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE2C37B401; Wed, 4 Jun 2003 05:26:06 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id D693643FBD; Wed, 4 Jun 2003 05:26:03 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 02D021B212; Wed, 4 Jun 2003 13:26:02 +0100 (BST) Date: Wed, 4 Jun 2003 13:26:02 +0100 From: Paul Richards To: Doug Rabson Message-ID: <20030604122602.GC68108@survey.codeburst.net> References: <20030603134717.GD35187@survey.codeburst.net> <20030603.085659.13314075.imp@bsdimp.com> <20030603155157.GH35187@survey.codeburst.net> <20030603.111956.46316212.imp@bsdimp.com> <1054584260.85972.26.camel@cf.freebsd-services.com> <1054724940.32568.6.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054724940.32568.6.camel@builder02.qubesoft.com> User-Agent: Mutt/1.5.4i cc: des@freebsd.org cc: hmp@freebsd.org cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: VFS: C99 sparse format for struct vfsops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 12:26:06 -0000 On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote: > On Mon, 2003-06-02 at 21:04, Paul Richards wrote: > > On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote: > > > > > > Notice how thread 1's _m gets set based on the results of the kobj > > > lookup, and we have a race, even if thread1 and thread2 took out their > > > driver instance locks. > > > > That means we have to lock the dispatch table before every method is > > looked up and hold it until the method returns (the alternative would be > > to free it inside the method once it had been called but that'd be a > > right mess). > > Don't even think about trying to put a mutex into the kobj dispatch I wasn't, I was just pointing out what would be necessary if the cacheing problem wasn't resolved :-) -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician]