Re: kldunload DIAGNOSTIC idea...

• Previous message: Nicolas Souchu: "Re: some PRs"
• In reply to: Poul-Henning Kamp: "kldunload DIAGNOSTIC idea..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 21 Jul 2004 08:16:56 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

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.
_______________________________________________
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: Nicolas Souchu: "Re: some PRs"
• In reply to: Poul-Henning Kamp: "kldunload DIAGNOSTIC idea..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]