From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 06:17:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F54816A4CE for ; Wed, 21 Jul 2004 06:17:32 +0000 (GMT) Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A00843D62 for ; Wed, 21 Jul 2004 06:17:30 +0000 (GMT) (envelope-from andrea@webcom.it) Received: from 213-140-17-96.fastres.net [::ffff:213.140.17.96] by mid-2.inet.it via I-SMTP-5.1.11-51A id ::ffff:213.140.17.96+hWitoN3eLDk; Wed, 21 Jul 2004 08:17:28 +0200 Received: by brian.webcom.it (Postfix, from userid 1000) id 13C5EA7; Wed, 21 Jul 2004 08:16:56 +0200 (CEST) Date: Wed, 21 Jul 2004 08:16:56 +0200 From: Andrea Campi To: Poul-Henning Kamp Message-ID: <20040721061656.GA3636@webcom.it> References: <75243.1090347623@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75243.1090347623@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 06:17:32 -0000 On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > I'm pulling hair out trying to make it guaranteed safe to unload device > driver modules, and the major pain here is to make sure there is no > thread stuck somewhere inside the code. > > That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > run through the proc/thread table and look for any thread with an > instruction counter inside the range of pages we are going to unload. A wild idea just struck; I'm going to just expose it as I think, so bear with me. Assumption: the main reason for wanting to unload the driver is to be able to reload a new (maybe different) one. The main concern is not freeing memory. Assumption: we are talking about cases where the driver wasn't able to clean everything up in the quiesce phase. This means SOME resources failed to be cleaned up, or we couldn't even try to free them, or we don't even know them. Assumption: we are NOT talking about the case you mentioned in a previous thread, where you may have some buffer, maybe mapped in common by an expansion card and by the driver. There's not much we can do there. We're just talking of a simpler case where we (think we) know we have a thread stuck somewhere, but apart from that, we're reasonably sure we can detach. Right? Ok, under this assumptions I guess the cleanest way is to go forward and detach the driver leaving it in memory. Either the quiesce or the unload should set appropriate flags that instruct the driver to abort any further activity, so you can simply and safely do: xx_send() { if (quiesced) return; ... lengthy_function(); <<< we are sleeping somewhere down there if (gone) return; ... } Yes, this requires additional checks to be scattered around, but it's going to be opt-in. In addition, it only needs to be done in places where lenghty_function() can't be cancelled, and I guess that's not going to be an awful lot of places. But I can be wrong. In addition, this may still leak memory, unless the driver is capable of keeping track and still free data in the gone case. Thoughts? Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look.