From owner-freebsd-smp Thu Aug 1 4:34:39 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 A56AF37B400 for ; Thu, 1 Aug 2002 04:34:34 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1898E43E42 for ; Thu, 1 Aug 2002 04:34:30 -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 HAA06179; Thu, 1 Aug 2002 07:34:29 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g71BXxP16543; Thu, 1 Aug 2002 07:33:59 -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.7335.156003.394975@grasshopper.cs.duke.edu> Date: Thu, 1 Aug 2002 07:33:59 -0400 (EDT) To: Terry Lambert Cc: freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers In-Reply-To: <3D48D163.2213890@mindspring.com> 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> <3D48D163.2213890@mindspring.com> 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 Terry Lambert writes: > 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? I (and most network drivers) need to call MGETHDR to restock receive buffers from the interrupt handler. When the per-cpu container runs out of mbufs, the system calls mb_pop_cont(). This calls kmem_malloc() to allocate storage for more mbufs: <...> kmem_malloc(c1579000,1000,1,1fa,c03395de) at kmem_malloc+0x1b5 mb_pop_cont(c03a54a0,1,c156c120,283,0) at mb_pop_cont+0xa8 mb_alloc(c03a54a0,1,1,0,0) at mb_alloc+0x1ec m_gethdr(1,1,c03a4400,c4203b4c,c158e100) at m_gethdr+0x34 gm_bsd_ether_rxeof(c4203000,34,7b3c,c0372040,0) at gm_bsd_ether_rxeof+0xcd <...> Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message