Date: Tue, 16 Jan 2001 17:13:53 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Bosko Milekic <bmilekic@technokratis.com> 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: <20010116171353.A7240@fw.wintelcom.net> In-Reply-To: <005001c0801d$9e2ead80$1f90c918@jehovah>; from bmilekic@technokratis.com on Tue, Jan 16, 2001 at 07:37:05PM -0500 References: <XFMail.010115233233.jhb@FreeBSD.org> <005001c0801d$9e2ead80$1f90c918@jehovah>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@technokratis.com> [010116 16:35] wrote: > > jhb wrote: > > [...] > > >> Right now all network drivers are not MP safe, so they all get Giant > first > > >> thing, so you won't hit this. Same for all syscalls (or all the ones > > >> hitting > > >> network code at least) so this will always be a recursion. When drivers > are > > >> marked as MP safe, then the locking will have to be fixed such that they > > >> don't > > >> call into mbuf allocation with their lock held if they can help it. > > > > > > Ok, then what were the panic's you and Jake were discussing on IRC > > > related to? I thought it was directly related to the out of order > > > locking on the driverlock. > > > > ?? I need some context. :) I had one lockup today involving some kind of > > deadlock in the lockmgr (*blam* *blam* x 12 to the lockmgr) and Jake had > > several panic's with the preemptive kernel stuff probably. That and we > mumbled > > on about guaranteeing that Giant is always first in the lock order. Other > than > > that I'm not sure what you are recalling. > > The discussed situation was probably a lock order reversal w.r.t. Giant and > some driver lock (in an MP safe driver). In one case, as you mentionned, > Giant can be acquired before the driver lock (the ifconfig case you spoke of, > when the call is originating from a system call), but in the interrupt case, > the driver lock would be acquired first, followed by Giant in the allocation > routines. > > 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. 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." 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?20010116171353.A7240>