On Mon, Aug 20, 2007 at 03:12:00PM +0200, Renzo Davoli wrote: > http://www.cs.unibo.it/~renzo/utrace. > > 2- Access to traced process vm. > > > This patch is very important: with this change VM hypervisors can access > their process memory efficiently. > > > > I propose a new call: > > int utrace_access_process_vm(struct task_struct *tsk, unsigned long addr, char __user *ubuf, int len, int write, int string); "string" smells like a hack, someone will come up with his favourite structure and ask for flag for copying, say, single-linked lists. :( > > which give I-O access to the memory of the process. > I have seen that access_process_vm has been exported to modules: it is a > change included in mainstream 2.6.23 from the first rc. > so I have exported access_process_vm_user too. > access_process_vm_user has two main differences with > access_process_vm: > - it copies a memory area directly from a process vm to the user space > of current and viceversa (it uses an internal one page buffer, check for allocation failure > it does > not need extra buffers or extra code loops). > - it supports the "string" flag for reading: no useless copies of data > after the end of string, no memory errors due to short string read > into large buffers. > > utrace_access_process_vm can be kept or not: modules can call it instead > of directly accessing access_process_vm_user when they need to check > that the requesting process has the right to access the other process > vm. > > > > 3- In the patch I have also implemented the support for PTRACE_MULTI > > and PTRACE_SYSVM. PTRACE_MULTI is horrible, it is asking for pain with compat version. > Several ptrace based application could > benefit from these features (e.g. when they need to load chunks of > memory or chunks of registers, burst of ptrace calls could be sent as a > single call reducing the number of mode switches). Mode switches are fast. This is a reason why read(2) doesn't have batched version, and read is called waaay more often than ptrace. I also wonder if this was tested with list debugging on: iterating over RCU protected list backwards when prev pointers are poisoned shouldn't work.
