site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=ZaeUs2poDVqa47VeDKGTNel9CMHi/ivegNfcb87GAgibQsRIn0gk6/ihaurHQ0irM9eJ2TOODPXUvdY0I1+u/p/PrxJia3qKv4H7iwYIr2axRxv9eYop82rWD17UoFGFjRzuRhT0fmfus7psiVTT6nNp7FxOyvn1Q3stNTfNLw4= Hi I posted on this earlier, but here's another attempt with a different slant. I'm really stuck on this after much searching, reading and experimentation, and would appreciate any thoughts. Do you see any "gotchas" or anything "bad" with using any of the following calls - vm_region, vm_protect, vm_read, vm_write, vm_machine_attribute - on current_map() from within the process context in kernel mode? I use these calls from within the kernel to write instructions to a process's address space. I had to use the VM_PROT_COPY flag when the user address in question was in the commpage area. It appears that the kernel gets unhandled faults on any further accesses to the commpage (such as by ntpd). My understanding: the commpage (0xffff8000-0xffffefff) is mapped shared and read-only into every process's space. Since my target process now wants to write to it, and changed protections to COW, the kernel creates a separate backing store for the overwritten pages. This should not affect either the protections, or the contents, or the sharing level, of the commpages for any other process. On a related note, gdb seems to get away with doing this -- What am I missing? Thanks Chandra _______________________________________________ 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