Date: Thu, 1 Aug 2002 12:48:55 -0500 From: Alan Cox <alc@cs.rice.edu> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Peter Wemm <peter@wemm.org>, John Baldwin <jhb@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <20020801174855.GE9934@cs.rice.edu> In-Reply-To: <15689.8042.488037.968605@grasshopper.cs.duke.edu> References: <XFMail.20020729175342.jhb@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020801174855.GE9934>