Problem with g_unload_class()

Poul-Henning Kamp phk at phk.freebsd.dk
Fri Mar 26 02:55:17 PST 2004


Hi, this just to say that I have not forgot you.

The underlying problem is how we want unloading to work.  There are two
sensible an one bad way it could work:

sensible 1:
	"I tried to unload, but couldn't, nothing has changed".

sensible 2:
	"I forcefully unloaded, you probably lost some data"

silly:
	"I couldn't unload and couldn't.  A lot of stuff got modified
	and the module is now only half functional.

I'd prefer we have it be the first two (controlled by an option) but
currently we're sort of stuck in the bottom one.

In message <20040322211631.S636 at korben.in.tern>, Lukas Ertl writes:
>Hi Poul,
>
>I'm having a problem with a change you committed to geom_subr.c in
>rev.1.74, where you changed g_unload_class() from a LIST_FOREACH() to a
>for(;;).
>
>One of the vinum classes I'm tinkering with uses the slice code as a base
>class to slice up the underlying device.  Now, with this particular
>commit, I get the following on kldunload:
>
>*) when my class provides a destroy method itself, it hangs endlessly in
>   this 'for (;;)' loop (maybe it's because I load multiple classes in
>   one module?).
>*) when relying on the destroy method of the slice class, I get a panic in
>   g_slice_spoiled(), apparently because it was passed a NULL pointer
>   which is dereferenced at "gp = cp->geom;".
>
>Unfortunately, I wasn't yet able to really debug this, since in the first
>case it won't let me break out to the debugger, and in the second case I
>can't get a usable coredump (see my mails to -current in the last few
>days).
>
>Of course, I don't expect you to find a solution in your magic ball, but I
>thought maybe you have some ideas about that.
>
>thanks,
>le
>
>-- 
>Lukas Ertl                           http://mailbox.univie.ac.at/~le/
>le at FreeBSD.org                       http://people.freebsd.org/~le/
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.


More information about the freebsd-geom mailing list