lkml.org 
[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [OKS] Module removal
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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.057 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site