Re: Device count (to be done with)

[Keith Owens <kaos@ocs.com.au>]

On Tue, 16 Oct 2001 00:02:22 -0700, 
David Brownell <david-b@pacbell.net> wrote:
>I'll have to repeat myself, then, until the point sticks or is refuted:
>TWO POLICIES are needed:
>
>    - One for normal operation, no sysadmin or developer involved.
>       That's the policy where both counts must be zero before it's
>       OK to unload.
>
>    - Separately, a policy whereby sysadmins can ignore what
>      Stamatis has called the "should-count" (matching how many
>      drivers are using the device).  Sysadmins (and developers)
>      need to be able to swap drivers, in cases where normal
>      operational safeguards don't apply.

That can be handled fairly easily.

* Add a separate count in the kernel, pointed to by the kernel_data
  field of the module header (this is why I added kernel_data).  This
  count is the "should" count.

* Report module use count as the sum of the existing use count plus the
  "should" count.  No changes to syscall, modutils or proc interfaces :).

* Kernel adds /proc/sys/kernel/modules/foo/should_count (needs a better name).
  echo "+1" > /proc/sys/kernel/modules/foo/should_count
  echo "-1" > /proc/sys/kernel/modules/foo/should_count
  cat /proc/sys/kernel/modules/foo/should_count reports existing count,
  for each module foo.

* To remove the module, take the "should" count to 0.  As long as the
  existing module use count is zero, you can unload the module.
  echo "0" > /proc/sys/kernel/modules/foo/should_count

Does the sysadmin need to note the count before clearing it and reset
the count after reloading?  Probably not, hotplug events should set the
count on reload.

Do you realise that you are close to reinventing Rusty Russell's module
redesign?  2.5 modules will have four module functions, instead of the
current two.

 module_load() - grab hardware, can fail.
 module_register() - make module available to other code, cannot fail.
 module_unregister() - remove access from other code, can fail.
 module_unload() - free hardware, cannot fail.

The normal 2.5 module life cycle is :-

  (1) Load.
  (2) Register.
  (3) rmmod, use count is 0.
  (4) Unregister.  No new code can use the module, existing users who
      have just entered will run to completion.  It is assumed that the
      module will notify these users that it is going away, e.g.
      return EOF.
  (5) Synchronize kernel.  This flushes out any users who have entered
      the module but not yet left.  They either leave or set
      MOD_INC_USE_COUNT.
  (6) Unload.

There is a perennial race in module unloading:

  CPU 0                                 CPU 1
  rmmod checks use count
  use count is 0
  syscall delete_module
  use count is still 0
					module is still registered, user
					enters the module
  module unregisters
  use count is still 0
					MOD_INC_USE_COUNT
  unload module
					Oops

The 2.5 redesign removes this race.  It will ensure that a module is
not removed until it is guaranteed that no user is running anywhere in
the module code.  In the race above, the life cycle would be :-

  (1) Load.
  (2) Register.
  (3) rmmod, use count is 0.
  (4) User enters module on cpu 1.
  (5) Unregister on cpu 0.
  (6) User does MOD_INC_USE_COUNT on cpu 1.
  (7) Synchronize kernel.
  (8) Use count is now 1, rmmod lost the race, go back to (2).

There is a nice side effect of separating hardware and software module
functions.  You will be able to say "rmmod -f" to force a module
unload.  That will go :-

  (1) Load.
  (2) Register.
  (3) rmmod -f, ignore use count.
  (4) Unregister.
  (5) Synchronize kernel.
  (6) Wait for use count to go to 0.
  (7) Unload.

Modules can define their own functions to decide if they can be
unloaded or not.  A module that does this shows up with a use count of
-1, rmmod does not check the use count, instead it calls the module's
can_unload() function.  can_unload() does whatever the module wants,
including checking other counts.  You can already do this on 2.4.

The problem with 2.4 is that there is no way to pass a flag to syscall
delete_module() so the module cannot tell the difference between rmmod,
rmmod -a and rmmod -f.  Rusty and I need to sort this out for 2.5.
With the above design and the ability to pass flags to delete_module(),
you probably do not need /proc/sys/kernel/modules/foo/should_count.
The module decides if it can be unloaded or not.

>I've never heard of a requirement that new kernels work with old
>modutilis (quite the opposite in fact). 

Some users don't read Documentation/Changes and run old modutils on new
kernels.  I even have to worry about the idiots who run modutils
2.1.121 on 2.4 kernels :(.  They do not get the full functionality of
the new modutils but they must not crash either.  That is, old modutils
on new kernels must be fail safe, I cannot make any incompatible
interface changes in stable kernels or utilities.

2.5 will break modules all over the place, as long as I get my changes
in early enough to let distributions ship the correct utilities.


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel