From owner-freebsd-smp Wed Jul 31 23:13:55 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2D2237B400; Wed, 31 Jul 2002 23:13:52 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55E7E43E42; Wed, 31 Jul 2002 23:13:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0019.cvx21-bradley.dialup.earthlink.net ([209.179.192.19] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17a9DR-0002yj-00; Wed, 31 Jul 2002 23:13:41 -0700 Message-ID: <3D48D163.2213890@mindspring.com> Date: Wed, 31 Jul 2002 23:12:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox Cc: Andrew Gallatin , Peter Wemm , John Baldwin , freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers References: <20020730000345.E0D9F2A7D6@canning.wemm.org> <15686.48913.150407.307190@grasshopper.cs.duke.edu> <20020730171226.GA26599@cs.rice.edu> <15688.22002.772933.316104@grasshopper.cs.duke.edu> <20020801021235.GD9934@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alan Cox wrote: > On Wed, Jul 31, 2002 at 05:26:10PM -0400, Andrew Gallatin wrote: > > > > For what its worth, this *seems* to work OK on a non-WITNESS, > > non-INVARIENTs kernel. > > That's what I would expect. The difficult problem that we'll have > with kmem_malloc() and friends stems from legacy drivers that rely on > Giant, not a properly locked driver. If a legacy driver sleeps because > kmem_malloc() is unable to acquire the mb_map or kernel_map lock, they > may wake up to an inconsistent state. Right now, requiring Giant in > the top half of the kernel to call kmem_malloc() et al. prevents this. Why the heck is a driver calling this anyway? Why the heck is there *anything* in the driver that needs a lock that's not implicit in the fact that it's called to process an interrupt? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message