Date: Tue, 16 Jan 2001 17:24:37 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Bosko Milekic <bmilekic@technokratis.com> Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <XFMail.010116172437.jhb@FreeBSD.org> In-Reply-To: <20010116171353.A7240@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-Jan-01 Alfred Perlstein wrote: > * 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 panic is much easier to debug than a deadlock. > A fix would be to DROP_GIANT on entry into a driver, or make kmem_alloc > not require Giant. The latter is preferable, but that would mean locking down vm. Are you volunteering? :) -- 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/ 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?XFMail.010116172437.jhb>