From owner-freebsd-geom@FreeBSD.ORG Fri Mar 26 02:55:17 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C683016A4D1; Fri, 26 Mar 2004 02:55:17 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECC6143D3F; Fri, 26 Mar 2004 02:55:16 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i2QAtEuN001265; Fri, 26 Mar 2004 11:55:15 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Lukas Ertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Mar 2004 21:27:51 +0100." <20040322211631.S636@korben.in.tern> Date: Fri, 26 Mar 2004 11:55:14 +0100 Message-ID: <1264.1080298514@critter.freebsd.dk> cc: geom@FreeBSD.org Subject: Re: Problem with g_unload_class() X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2004 10:55:17 -0000 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@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@FreeBSD.org http://people.freebsd.org/~le/ > -- 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.