Re: kldunload DIAGNOSTIC idea...
From: Scott Long (scottl_at_samsco.org)
Date: 07/20/04
- Previous message: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Brian Fundakowski Feldman: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Andrea Campi: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 20 Jul 2004 13:08:54 -0600 To: Brian Fundakowski Feldman <green@freebsd.org>
Brian Fundakowski Feldman wrote:
> 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?
>
This is better than phk's suggestion since you can have module code
that calls out to another part of the system and blocks. Still, it's
not 100% perfect. There are all sorts of APIs out there that do async
callbacks, and it really should be up to the driver to track these
things.
Scott
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Brian Fundakowski Feldman: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Andrea Campi: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|