Date: Tue, 16 Jan 2001 19:37:05 -0500 From: "Bosko Milekic" <bmilekic@technokratis.com> To: "John Baldwin" <jhb@FreeBSD.org>, "Alfred Perlstein" <bright@wintelcom.net> Cc: <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <005001c0801d$9e2ead80$1f90c918@jehovah> References: <XFMail.010115233233.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > -- > > John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Cheers, 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?005001c0801d$9e2ead80$1f90c918>