From owner-freebsd-smp Thu Aug 1 10:49: 1 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 600CD37B400; Thu, 1 Aug 2002 10:48:57 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0139F43E4A; Thu, 1 Aug 2002 10:48:57 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 7921E4A9F1; Thu, 1 Aug 2002 12:48:56 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 0516D4A9C7; Thu, 1 Aug 2002 12:48:56 -0500 (CDT) Date: Thu, 1 Aug 2002 12:48:55 -0500 From: Alan Cox To: Andrew Gallatin Cc: Peter Wemm , John Baldwin , freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <20020801174855.GE9934@cs.rice.edu> 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> <15689.8042.488037.968605@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15689.8042.488037.968605@grasshopper.cs.duke.edu> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by AMaViS snapshot-20020300 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 On Thu, Aug 01, 2002 at 07:45:46AM -0400, Andrew Gallatin wrote: > > Alan Cox writes: > > 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. > > > > Alan > > A legacy driver will already hold Giant in its interrupt handler by > virtue of ithread_loop() acquiring Giant for it: > > if ((ih->ih_flags & IH_MPSAFE) == 0) > mtx_lock(&Giant); > ih->ih_handler(ih->ih_argument); > if ((ih->ih_flags & IH_MPSAFE) == 0) > mtx_unlock(&Giant); > > So how does requiring Giant in the top half help here? You're not being dense. :-) It's subtle. By requiring a top-half thread to hold Giant before acquiring the kernel_map or mb_map locks, we are guaranteeing to the legacy driver that those locks will be free once they get Giant. Consequently, the driver won't be put to sleep in mid operation because it failed to get the kernel_map or mb_map lock. In -STABLE, the same result is achieved via an splvm()/splx() prior to acquiring these locks. (Remember, even -STABLE has vm map locks.) > I'm sorry if I'm being dense, but there's a lot about the > synchronization requirements in -current that I don't understand. Regards, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message