Re: Using ifnet pointers safely
Re: Using ifnet pointers safely
- Subject: Re: Using ifnet pointers safely
- From: Peter Lovell <email@hidden>
- Date: Fri, 25 Oct 2002 13:56:18 -0400
Hi Michael,
in working on socket NKEs, I've found "TCP/IP Illustrated, Vol
2" by Wright & Stevens to be a great help, in addition to
Stevens's other books. There's a section in there on interrupt
levels and concurrency.
This deals with BSD in general, rather than OS X in particular.
The same general rules apply though because otherwise the whole
stack would be failing.
The splnet(), splx() etc routines in their original BSD
implementation managed concurrency by controlling interrupt
levels. As has been noted, this is insufficient for MP systems.
On OS X, they are calls into the funnel mechanism and no longer
work by adjusting interrupt levels. Note that there are no
levels - the network lock is an all-or-nothing lock. The kernel
lock is similar. And you can't hold both of them, only one or
the other. You'll also see code which switches between, starting
out with kernel lock and switching to network lock when dealing
with network structures. The code for processing ioctls is a
good example of this behaviour.
On Thursday, October 24, 2002, at 08:17 PM, Michael Cashwell wrote:
During this section of code I have the network funnel. If I understand
correctly, that protects me from any other running thread (even on MP
systems). Again, can someone confirm?
Yes, you're protected.
My real worry is about my own thread's behavior. I understand that
kernel threads can block and if they do then I loose and regain the
funnel. But since I can avoid making calls that block I can handle
that. But what about preemption? If my thread runs out of its time
quantum might it get preempted (and again loose and regain the funnel)?
My understanding is that the time quantum runout is deferred
until the kernel processing is finished. I'm not certain of
that, though, so hopefully someone else on the list can confirm.
But sanity dictates that this must be so. Otherwise you'd always
be running the risk of leaving kernel structures in inconsistent
states. Think about what would happen if time ran out while
tcp_output was part way through processing an mbuf to end. Ouch.
And lastly, whatever the solution to that is ("kernel threads can't be
preempted" or "use splnet() / splx()", or something else), what about
paths into my NKE that are really user threads that have called into
the kernel (through the network stack)? (Can that happen or is
everything in the kernel run on a kernel thread with the "call" handled
via a kernel thread blocking on a queue?) If it can happen, do I need
to consider such threads as different from native kernel threads as far
as preemption in my NKE goes?
Output and input processing are handled differently. It helps to
think of output as a synchronous process, done in response to a
syscall from user-land. It operates in kernel mode, but in a way
it's something like an extended function call.
Input is handled on an interrupt-driven basis, and not in the
context of the target user or process. Part of the processing is
done directly in response to the hardware interrupt and some is
queued, as I understand, but it's not in the user thread or
context etc.
Regards.....Peter
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.