site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 3 févr. 06, at 18:10, Josh Graessley wrote: R/W locks look to be the solution for this case. That's what I'm doing, with a fine granularity if possible. Are the re-injection KPIs concerned? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. Other changes are possible too. Too avoid headaches, you need to be very careful with your locking. Lock only while manipulating shared data structures. Never hold a lock while calling back in to the stack, you never know when the stack might turn around and call your kext. This email sent to site_archiver@lists.apple.com