From owner-cvs-all Tue Jan 16 17:29:43 2001 Delivered-To: cvs-all@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id BF7F037B6A1; Tue, 16 Jan 2001 17:29:16 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7A9GR03.6HA; Tue, 16 Jan 2001 20:29:15 -0500 Message-ID: <026b01c08025$1c12bff0$1f90c918@jehovah> From: "Bosko Milekic" To: "Alfred Perlstein" Cc: "John Baldwin" , , References: <005001c0801d$9e2ead80$1f90c918@jehovah> <20010116171353.A7240@fw.wintelcom.net> Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Date: Tue, 16 Jan 2001 20:30:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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