Re: KPI Interface filter and filter detachment
Re: KPI Interface filter and filter detachment
- Subject: Re: KPI Interface filter and filter detachment
- From: Stephane Sudre <email@hidden>
- Date: Fri, 3 Feb 2006 19:15:23 +0100
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).
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.
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?
_______________________________________________
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