Re: Networking Timers

[Chuck Winters <cwinters@atl.lmco.com>]

Where can I find a list of the kernel functions which sleep?

Chuck

On Sun, Jan 06, 2002 at 12:42:41AM -0500, Lisa & Eric Malkowski wrote:
> To answer your question to kernelnewbies:
> 
> Any kernel timer that goes off runs in the timer bottom half context.
> kernel timers are registered with the add_timer() call.
> 
> So, yes since the TCP retransmit timer is simply a generic kernel timer,
> the function that gets called when the timer goes off is running in
> bottom half context.
> 
> In bottom half context you have to be careful to realize that it can
> interrupt code that runs in kernel space that was entered by a process
> making a system call.  You also need to use GFP_ATOMIC when allocating
> memory in bottom half context with kmalloc() or alloc_skb() for
> example.  You do not want to call anything that can sleep in bottom half
> context either (hence the need for GFP_ATOMIC for memory allocation
> level).
> 
> So if you've got a data structure that is shared between code that runs
> in "user context" -- a process entering a system call like for example a
> read operation on a socket and code that runs in bottom half context
> (like a timer or network packet received), then the bottom half context
> code can just access the data structure normally and the user space
> context code can call start_bh_atomic(), do it's stuff w/ the shared
> data structure, and end_bh_atomic() when done w/ the data structure.
> When start_bh_atomic() is active, all of the bottom halves don't run
> until end_bh_atomic() is called.  Be careful when you call
> start_bh_atomic() to not forget to end_bh_atmoic() eventually or you
> will hang your system.  It's good practice to keep code between
> start/end_bh_atomic pairs short and sweet to not make the system
> sluggish or back the bottom halves up too much.
> 
> Also bottom halves are atomic from one another.  So for example if you
> have a data structure that's shared between timer bottom half, network
> bottom half, and kernel context code, both the timer bottom half context
> function and network bottom half function don't have to worry about
> stomping on each other and the user context code uses start_bh_atomic()
> to keep the timer and network BHs out while it mucks with any shared
> structure.  I've seen words that state that BHs are even atomic on SMP
> systems (which can have interrupts on different CPUs occurring and it's
> the interrupt service routines that usually schedule the BHs to run).
> 
> As mentioned above, add_timer() adds a function to be called when a
> timer goes off.  In case you're curious, to register a function to be
> called in the network BH, you can use dev_add_pack() to select something
> to be called when a particular packet type comes in off an ethernet
> device.  The function you register will run in network BH context when
> it's called.
> 
> This all applies to kernel 2.2.X.  I'm not sure what additional
> provisions might need to be taken in the 2.4.X kernel series.  I haven't
> had to port any of my code to 2.4.X yet, but I anticipate I'll make the
> plunge eventually.
> 
> I'm cc'ing this to the list in case something I said isn't 100%
> accurate.  Paul Russell's guides are essential when making sure your
> code isn't going to have problems with race conditions and proofing it
> to make sure it follows the rules of programming in kernel space such
> that you don't have to worry about hanging up your machine in a
> mysterious manner.
> 
> Good luck,
> 
> -Eric Malkowski
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/