From owner-cvs-all Tue Jan 16 17:25: 6 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id BA0EA37B69F; Tue, 16 Jan 2001 17:24:39 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0H1MlL23613; Tue, 16 Jan 2001 17:22:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010116171353.A7240@fw.wintelcom.net> Date: Tue, 16 Jan 2001 17:24:37 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Bosko Milekic Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Jan-01 Alfred Perlstein wrote: > * Bosko Milekic [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 -- 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