On Tue, 2 Jul 2002 00:11:52 -0300,
Werner Almesberger <wa@almesberger.net> wrote:
>Keith Owens wrote:
>> This is just one symptom of the overall problem, which is module code
>> that adjusts its use count by executing code that belongs to the
>> module. The same problem exists on entry to a module function, the
>> module can be removed before MOD_INC_USE_COUNT is reached.
>
>Ah yes, now I remember, thanks. I filed that under "improper reference
>tracking". After all, why would anybody hold an uncounted reference in
>the first place ?
All functions passed to registration routines by modules are uncounted
references. A module is loaded, registers its operations and exits
from the cleanup routine. At that point its use count is 0, even
though it there are references to the module from tables outside the
module.
When the open routine (or its equivalent) is called, then the use count
is incremented from within the module. The executing code between
if (ops->open)
ops->open();
and MOD_INC_USE_COUNT in the module's open routine is racy, there is no
lock that prevents the module being removed while the start of the open
routine is being executed.
Incrementing the use count at registration time is no good, it stops
the module being unloaded. Operations are deregistered at rmmod time.
Setting the use count at registration prevents rmmod from removing the
module, so you cannot deregister the operations. Catch 22.
Module unload is not racy on UP without preempt. It is racy on SMP or
with preempt. It used to be safe on SMP because almost everything was
under the BKL, but that protection no longer exists.
-
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/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:08 EST