Date: Tue, 9 Jul 2002 08:25:56 +0200 (CEST)
From: Roman Zippel <zippel@linux-m68k.org>
To: Keith Owens <kaos@ocs.com.au>
cc: linux-kernel@vger.kernel.org
Subject: Re: [OKS] Module removal 
In-Reply-To: <22226.1026174466@ocs3.intra.ocs.com.au>
Message-ID: <Pine.LNX.4.44.0207090744180.8911-100000@serv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1521
Lines: 35

Hi,

On Tue, 9 Jul 2002, Keith Owens wrote:

>   Check use count.
>   Unregister.
>   Ensure that all code that had a reference to the module has either
>   dropped that reference or bumped the use count.
>   Check use count again, it may have been bumped above.
>   If use count is still 0, there are no stale references left.  It is
>   now safe to unload, call the module unallocate routine then free its
>   area.
>   If use count != 0, either schedule for removal when the count goes to
>   0 or reregister.  I prefer reregister, Rusty prefers delayed removal.
>
> Ensuring that all code has either dropped stale references or bumped
> the use count means that all processes that were not sleeping when
> rmmod was started must proceed to a sync point.  It is (and always has
> been) illegal to sleep while using module code/data (note: using, not
> referencing).

Who is changing the use count? How do you ensure that someone doesn't
cache a reference past that magic sync point?
IMO the real problem is that cleanup_module() can't fail. If modules
already do proper data acounting, it's not too difficult to detect if
there still exists a reference. In the driverfs example the problem is
that remove_driver() returns void instead of int, so it can't fail.

bye, Roman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/