> In article <Pine.LNX.3.95.981230223937.1979A-100000@localhost>,
> groudier@club-internet.fr (Gerard Roudier) writes:
> > Is it safe for a module to release its resources without being careful
> > about timers referencing these resources being active ?
>
> No.
Obviously. I just was unsure that all Linux modules are actually careful
of that. ;-)
> > If NO is the answer, is it enough to just try to delete active timers?
>
> Should be enough (but make sure you kill all timers)
I donnot think so, at least for 2.2 in SMP mode:
The module code acquires the kernel lock, but the timer BH stuff does not,
it seems. If this is true, then the following situation may be considered:
- The module unload stuff is executed bu CPU 1.
- A timer having 'data argument' referencing a memory resource freeed on
module release is still active.
- The timer BH is executed bu CPU 2 and calls the handler of this timer.
Then a race between CPU1 and CPU2 may lead to system destruction. :-)
The same problem seems to apply to free_irq() in the following situation:
- The module unload stuff is executed bu CPU 1.
- The IRQ is shared and another device raises the interrupt for this IRQ.
- The interrupt handling for this IRQ is started on CPU 2.
Same possible race that may lead to same result.
(BTW, we can consider that, if the module usage count is zero, it is very
unlikely an interrupt be generated for the IRQ of the device if it is not
shared)
Note that I donnot claim to be a kernel guru and it would not be a problem
if I just missed something important. And even if I am right, we may
consider such situations to be very unlikely, as every bug that has ever
existed. ;-)
Questions:
How many bugs? 2? 1? 0? Unlikely? Not unlikely? May happen on UP too?
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/