kern/43002: required>0 module autounload timestamp race

[pooka%iki.fi@localhost]

>Number:         43002
>Category:       kern
>Synopsis:       required>0 module autounload timestamp race
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 18 17:10:16 +0000 2010
>Originator:     Antti Kantee
>Release:        
>Organization:
>Environment:
>Description:
module autounload is attempted at exactly t_now + module_autotime
from load.

Let's say mod_a depends on mod_b.  When loading mod_a, mod_b is
loaded first.  Let's assume mod_b gets timestamp t and mod_a gets
timestamp t+1.

When the autounload thread runs, unload of mod_b is attempted at
t, but it fails since mod_a is still loaded.  mod_a is unloaded at
t+1, but autounload of mod_b will not be attempted anymore.  In
the worst case, n-1 modules in the dependency chain well be left
lingering.

mod_b will be autounloaded when the system is short on memory
(if it's not in use then), so this might be more of a cosmetic
issue.  At least I'm not aware of any application depending
on the module_autotime behavior.
>How-To-Repeat:
you lose some, you get unlucky now and then
>Fix:
tinker with timestamping or change autounload semantics