[Top] [All Lists]

Re: tx_timeout and timer serialisation

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: tx_timeout and timer serialisation
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Sat, 20 May 2000 13:35:57 +0800
Cc: Donald Becker <becker@xxxxxxxxx>, netdev@xxxxxxxxxxx, Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
In-reply-to: <39262113.19447850@xxxxxxxxxx>; from "Andrew Morton" on Sat, May 20, 2000 at 03:22:27PM
References: <3925BB00.B1CDDFE7@xxxxxxxxxxxxxxxx> <Pine.LNX.4.10.10005192039250.825-100000@xxxxxxxxxxxxx>, <Pine.LNX.4.10.10005192039250.825-100000@xxxxxxxxxxxxx>; <20000520122715.A7682@xxxxxxxxxxxxx> <39262113.19447850@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
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
> ( 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

Best regards

<Prev in Thread] Current Thread [Next in Thread>