Date: Tue, 16 Jan 2001 20:30:43 -0500 From: "Bosko Milekic" <bmilekic@technokratis.com> To: "Alfred Perlstein" <bright@wintelcom.net> Cc: "John Baldwin" <jhb@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <026b01c08025$1c12bff0$1f90c918@jehovah> References: <XFMail.010115233233.jhb@FreeBSD.org> <005001c0801d$9e2ead80$1f90c918@jehovah> <20010116171353.A7240@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
> > The "solution" is just to either make sure that we already own Giant, in
> > which case it's OK to get it again (recurse on it), OR that we don't own
> > Giant but that there are no other locks held (i.e. like a driver lock).
If
> > there are, then we just panic. Sure, right now, if you make a driver MP
Safe,
> > you want to make sure that you don't call the mbuf ALLOCATION/FREE code
with
> > any locks held. For the moment, anyway, this is the best solution as I
see
> > it. Later, we may want to do it differently, but for that we need the
entire
> > picture. This is where the "get it working before anything else"
philosophy
> > becomes useful.
>
> Your patch doesn't fix the deadlock, it only turns it into a panic.
That's right. The patch will CATCH bad guys. When they turn up, then we
fix them for the time being. The "fix" should be to drop all locks (except
Giant) before calling the mbuf allocation/free routines. Optionally, you can
also DROP_GIANT on entry to a driver which has as point-of-entry a system
call, but that solution shouldn't be used. See, right now, we're not 100%
sure on how we want to handle it, so we look for a method that works and that
requires the least diff bloat. If we do the DROP_GIANT thing, then we've
gotta change all the drivers. If we do the initial thing suggested above,
then we only have to do this for drivers we make MP safe. As I said, we may
eventually deal with it differently, if need be. The best thing to do right
now is to document all drivers being made MP safe and document specifics
about the implementation. We should list them somewhere so that we can get
back to this later.
> A fix would be to DROP_GIANT on entry into a driver, or make kmem_alloc
> not require Giant.
>
> --
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."
Later,
Bosko.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?026b01c08025$1c12bff0$1f90c918>