Re: kldunload DIAGNOSTIC idea...

From: David Schultz (das_at_FreeBSD.ORG)
Date: 07/20/04

  • Next message: Nicolas Souchu: "Re: some PRs" 
    Date: Tue, 20 Jul 2004 13:37:39 -0700
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    On Tue, Jul 20, 2004, Poul-Henning Kamp wrote:
    > 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.

    But this is just a heuristic that may sometimes fail. The module
    might be holding resources or locks, it could have callbacks, etc.
    If we're going to offer a forcible unload option, I think it's
    crucial that it be safe. That is, a system administrator must be
    able to use it on a production system and be confident that it
    will not cause anything bad to happen. Otherwise, it doesn't
    really buy you much.

    Also, doing this right (i.e. the hard way) may have other
    advantages. For instance, when any old module or driver fails an
    internal consistency check right now, or in some cases, simply
    fails to allocate memory, the best course of action we have right
    now is to panic and force a reboot of the machine. It might be
    worthwhile to see if some of those panics could be converted into
    ``forcibly reload the module and try again.'' This would require
    a lot of work to make sure everything gets cleaned up, but I think
    it would be worth it.
    _______________________________________________
    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"

  • Next message: Nicolas Souchu: "Re: some PRs"

    Relevant Pages

    • Re: kldunload DIAGNOSTIC idea...
      ... >>You mean any thread with a stack trace that includes an instruction ... > Looking for sleep addresses inside the module might make sense too. ... catch sleeps, pending timeouts, pending callouts, etc. ...
      (freebsd-arch)
    • RE: usb filter driver
      ... but retail build fails in both Win Me and win 98 ... >>> How do a get stack trace for it in SoftICE as I am also unable ... > I'm not familiar with SoftIce, so I'm not sure how you would get a stack ...
      (microsoft.public.development.device.drivers)
    • Re: Meaning/consequences of Unrestricted=true
      ... I can't get a stack trace, actually, as the exception comes up as soon as I ... either (guess it fails at ... The only thing I was able to get in my output window was the ... permission set. ...
      (microsoft.public.dotnet.security)
    • Re: Faillure to run .NET 2.0 app from UNC
      ... Based on the stack trace, it fails at the beginning ... have permission writing to that shared folder? ... Microsoft Online Community Support ...
      (microsoft.public.dotnet.framework)
    • Launching Matlab OSX Tiger
      ... Is there an FAQ or some instruction that describes why Matlab.app ... fails to locate the X11 server if a user other than the admin double ...
      (comp.soft-sys.matlab)