From owner-freebsd-current@FreeBSD.ORG Wed Jun 4 04:11:14 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 20DD237B401; Wed, 4 Jun 2003 04:11:14 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id D059743FAF; Wed, 4 Jun 2003 04:11:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.6) with ESMTP id h54B97ib000668; Wed, 4 Jun 2003 12:09:11 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h54B90dI050095; Wed, 4 Jun 2003 12:09:00 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Paul Richards In-Reply-To: <1054584260.85972.26.camel@cf.freebsd-services.com> 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> Content-Type: text/plain Organization: Message-Id: <1054724940.32568.6.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 04 Jun 2003 12:09:00 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 11:11:14 -0000 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 sequence. That would make the call several thousand times slower. We might as well write the kernel in Visual Basic. I've been thinking about this problem for a long time and I'm certain there is a way to make this safe without sacrificing performance. I have an idea I'm working on right now which should work (at least I haven't managed to disprove it so far) and which would have approximately the same performance profile as the current mechanism.