On Sat, May 20, 2000 at 03:22:27PM +1000, Andrew Morton wrote:
> Andrey Savochkin wrote:
> > I suppose, del_timer() call should be wrapped by
> > start_bh_atomic/end_bh_atomic pair which provides global serialization
> > against BHs.
> Those functions aren't present in 2.3... I guess they were unneeded
> because all the old-style BH's are sequentially run from within a single
> new-style tasklet, under global_bh_lock. So the old-style handlers are
> globally serialised.
I was addressing the remarks about 2.2 kernels.
We need to serialize the timer handler with outside code (which runs not in
BH or IRQ context). For 2.2 del_timer call should be in bh_atomic section.
In 2.3 kernels we no loner have bh_atomic stuff, but we have del_timer_sync
function. del_timer_sync solves most serialization problems, but not with
module unloading and freeing the memory where the code resides.
So, 2.2 kernels have a perfect solution which hasn't been widely deployed
yet. 2.3 kernels are really problematic ones.
> I have just written a little kernel module which has confirmed that the
> handler-keeps-running-after-del_timer bug exists in both 2.2.14 and
> 2.3.99-pre9. Not good. Very not good, IMO.
> I think I have a fix which will preserve the current (completely
> magical) timer semantics. It's ugly as sin, but that's the price.
> Later today, perhaps.
> The test module is at http://www.uow.edu.au/~andrewm/timertest.tar.gz
> ( I wanna know why my kernel thread shows up in ps as "insmod
> timertest.o" but everyone else's has nifty names like "[kflushd]" )
Because you haven't replaced the process name. Look at, for example, kswapd
start in mm/vmscan.c