Will, On Mon, Jan 15, 2007 at 04:51:14PM -0500, William Cohen wrote: > Hi, > > I have been taking a look at getting the perfmon patches working on the > Fedora > Core 7 (Raw Hide) Kernels. The Fedora Core kernels replace ptrace with > utrace > and a compatibility layer. The utrace patches remove the function > ptrace_check_attach() and the internals of ptrace are not generally > available. > > The ptrace_check_attach() make sure the process's perfmon context being > modified > is stopped and the performance monitoring state is in the process state > information. The stopped process restarted is restarted in user space with a > PTRACE_CONT call. Is there anything else that is going on with using ptrace > for perfmon2? > When operating in per-thread mode, perfmon2 needs to make sure the monitored thread is fully stopped before it must manipulate its state. Just checking that task->state is not enough, perfmon2 needs to wait until the task is actually OFF the CPU. It is important to note that perfmon2 does not invoke ptrace to stop the thread, this needs to be done by the user.
That is not because we can guarantee that the thread is off the cpu, that we are out of trouble. What would happen if the thread was woken up while we operate on it on an SMP system? There is important property of ptrace() which we leverage in perfmon2: ptrace maintains a ptrace parent, i.e, the thread (process) which controls the PTRACED thread. In other words, only one thread in the entire system may issue PTRACE commands to an already ptraced thread. I would hope that utrace duplicates this behavior as well. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
