site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Feb 3, 2006, at 10:15 AM, Stephane Sudre wrote: On 3 févr. 06, at 18:10, Josh Graessley wrote: That's what I'm doing, with a fine granularity if possible. -josh _______________________________________________ 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... This email sent to site_archiver@lists.apple.com 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. 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. smime.p7s