From owner-freebsd-arch@FreeBSD.ORG  Tue Jul 20 18:20:26 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 681F816A4CE
	for <arch@freebsd.org>; Tue, 20 Jul 2004 18:20:26 +0000 (GMT)
Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D6ABF43D31
	for <arch@freebsd.org>; Tue, 20 Jul 2004 18:20:25 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk
	[80.160.124.83])
	by pfepa.post.tele.dk (Postfix) with ESMTP id 343FF47FE2D
	for <arch@freebsd.org>; Tue, 20 Jul 2004 20:20:23 +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 i6KIKNrT075244
	for <arch@freebsd.org>; Tue, 20 Jul 2004 20:20:23 +0200 (CEST)
	(envelope-from phk@critter.freebsd.dk)
To: arch@freebsd.org
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 20 Jul 2004 20:20:23 +0200
Message-ID: <75243.1090347623@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Subject: 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:20:26 -0000


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 ?

-- 
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.