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