From owner-freebsd-arch@FreeBSD.ORG  Tue Jul 20 18:40:00 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 8758C16A4CE; Tue, 20 Jul 2004 18:40:00 +0000 (GMT)
Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 25A2C43D6A; Tue, 20 Jul 2004 18:40:00 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk
	[80.160.124.83])
	by pfepb.post.tele.dk (Postfix) with ESMTP id AE5C05EE072;
	Tue, 20 Jul 2004 20:39:58 +0200 (CEST)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6KIdvgf075605;
	Tue, 20 Jul 2004 20:39:58 +0200 (CEST)
	(envelope-from phk@critter.freebsd.dk)
To: Brian Fundakowski Feldman <green@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Tue, 20 Jul 2004 14:32:13 EDT."
             <20040720183213.GC1009@green.homeunix.org> 
Date: Tue, 20 Jul 2004 20:39:57 +0200
Message-ID: <75604.1090348797@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jul 2004 18:40:00 -0000

In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma
n writes:
>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.
>> 
>> Any takers ?
>
>You mean any thread with a stack trace that includes an instruction
>counter inside those pages, don't you?

That would require us to unwind the stack which I think is overkill
for the purpose.

The most likely case is that the thread is sleeping on something
inside the kld so just checking the instruction pointer would be
fine.

Looking for sleep addresses inside the module might make sense too.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.