From owner-freebsd-smp Thu Aug 1 4:53:48 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 5F74E37B400; Thu, 1 Aug 2002 04:53:43 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4B6643E75; Thu, 1 Aug 2002 04:52:18 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id HAA06411; Thu, 1 Aug 2002 07:46:16 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g71Bjkp16557; Thu, 1 Aug 2002 07:45:46 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15689.8042.488037.968605@grasshopper.cs.duke.edu> Date: Thu, 1 Aug 2002 07:45:46 -0400 (EDT) To: Alan Cox Cc: Peter Wemm , John Baldwin , freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers In-Reply-To: <20020801021235.GD9934@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> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 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? I'm sorry if I'm being dense, but there's a lot about the synchronization requirements in -current that I don't understand. Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message