Re: KPI Interface filter and filter detachment
Re: KPI Interface filter and filter detachment
- Subject: Re: KPI Interface filter and filter detachment
- From: Josh Graessley <email@hidden>
- Date: Fri, 3 Feb 2006 10:43:45 -0800
On Feb 3, 2006, at 10:15 AM, Stephane Sudre wrote:
On 3 févr. 06, at 18:10, Josh Graessley wrote:
As currently implemented, the iff_input callback is most likely to
occur on the dlil input thread. Your callback for handling data
sent on a kernel control socket will occur on the thread that calls
send/sendmsg/sendto. These are two different threads.
I was thinking that maybe a detach event could be sent via kernel
Event then a userland process would catch it and send a kern control
message to the kernel while it was in an iff_input callback, then
this could explain a recursive lock attempt. But from what you are
saying, this does not look possible (and if it was, I would not have
understood how things could be running ok).
That would never be a problem. The kernel never calls out in to a user
process. In the case of a kernel event socket, the kernel event is
queued in the kernel event socket's receive buffer. If the process has
a thread waiting on that data, the thread is kicked so it can read the
data (or if the socket is being waited on in select or a kqueue). That
thread would then perform the read and call the kernel control
socket's send.
The implementation may change in the future. You need to be very
careful. One day there may be multiple input threads.
R/W locks look to be the solution for this case.
Be very careful with R/W locks. They can cover up some problems that
you see immediately with a mutex. For example, the recursive lock
problem you may be seeing could be covered up if you only take the
lock for reading both times. This will likely fail in the rare case
that between taking the read the first time and the second time,
another thread attempts to take the lock for writing. The second read
will probably wait until the write has had a chance to take the lock.
The write won't succeed until all of the readers are done, including
the first read which will never complete because the thread is stuck
waiting to get the second read on the same lock.
Other changes are possible too. Too avoid headaches, you need to be
very careful with your locking. Lock only while manipulating shared
data structures.
That's what I'm doing, with a fine granularity if possible.
Never hold a lock while calling back in to the stack, you never
know when the stack might turn around and call your kext.
Are the re-injection KPIs concerned?
Absolutely. In fact, you'll probably get away with most mbuf
manipulation routines and a lot of other stuff. The place you'll
really get bit is holding the lock while injecting a packet in or out.
You never know what other kexts are going to do, or the stack for that
matter. Don't make assumptions. Unless you know for certain exactly
what will happen when you call a function with your lock held, move
the calling of that function out of the segment where you're holding a
lock.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden