> It seems like any solution requiring timer_exit() will always be racy,
> because of the [very small] window between timer_exit() code finishing,
> and the timer function code being disposeable...
timer_exit() was used not to resolve this race, but to plug
race window between releasing timer list spinlock and entry to timer handler.
The moment, when timer handler finds convenient to call timer_exit()
is not essential from this viewpoint. F.e it could call it on the most
entry upon grabbing some spinlock on controlled object.
No attempt to resolve "module unload" race was even made.
Moreover, I even think that this race could be resolved separately.
Even some big synchronizer called from module.c is acceptable.
Case of "self-modifying" code does not deserve too much of attention.
Actually, TIMER_SELF_DESTRUCTABLE flag or Andrew's approach
solve _all_ of the problems, provided timer->running remains public
for "asynchronous" timers and module.c synchronizes to TIMER_BH.