On Wednesday, May 29, 2002, at 06:27 PM, Andrew Gallatin wrote: Is it possible for a kext to overload system calls (or Mach traps) in Darwin? Is there any example code for doing this available? No, and I hope not, in that order! ;-) In fact the first part is not true. Almost all Mach calls are just messages to a port. Strategically override which port gets returned (and Mach provides facilities for this in many of the interesting cases), and you can interpose on all the calls. In this particular case, you could override which port gets returned by mach_task_self() via task_set_special_port(), and override all Task, Mach port, and VM operations to filter out the ones you want. But that's an awful lot of work for what you are trying to do. I have another module (an IOKit driver) which wires memory for OS-bypass communications for unbounded amounts of time. If the user-level application misbehaves and attempts to free this wired memory prior to unwiring it, the VM system blocks in vm_deallocate() waiting for the memory to be unwired. The IOKit driver has no idea the VM system wants the memory to be unwired. Deadlock ensues. There are two variants of the wiring calls allowed by Mach. One which keeps the pages in memory as long as they are mapped, but allows the mappings to be removed. Another keeps everything where it is because I/O is active. We shouldn't be doing the latter except when DMAs are active. You can use both on the same memory at the same time. If the former is already in place, the latter is quite efficient (just bumps up reference counts and removes them when the DMA wiring is removed). I think you just have to get the right mix. So I'd like to snoop vm_deallocate() calls & catch those which attempt free memory that the IOKit driver has wired down so that I can get the driver to unwire the memory (and do the required cleanup so that no more DMAs happen to that region, of course). What would be ideal would be an optional callback in the vm_map_entry_t that could be called in vm_map_delete(), so that the VM system can request that the memory be unwired & not simply deadlock. Callbacks are powerful, but dangerous, and very difficult to get right. For something like this, a more active approach where the DMA wirings are removed after the DMA is a more reasoned approach. This is true unless there is some reason you can't tell when the DMAs end. But then I would argue that is a problem with you user client model. We explicitly order port destructions before memory destructions on task death for just this very reason. When the port which represents the user client goes away, the reference on the driver goes away and that should un-wire the memory so that the vm_deallocate() calls to follow make forward progress. The same should work for explicit shutdown as well (you can't deallocate the memory until you close the device if the device is going to place a persistent hold on the memory). --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.