> Perfmon2 needs a way of flushing the perfmon registers internal to the > thread to a place that they can be read by another process. The ptrace > call was used to force that saving of thread state in a place that > another process could modify it. The utrace support doesn't make > trace_check_attach() used by perfmon2 available.
ptrace_check_attach is an internal function of the old ptrace implementation. It checks that the current thread is the ptracer of the given target thread, and that the target thread is in TASK_TRACED state (or immediately coercible to it). The semantics of TASK_TRACED guarantee that a thread so stopped can be woken only by ptrace or SIGKILL. The semantics of ptrace guarantee that the current thread and no other can use ptrace on the same target thread. Lastly, ptrace_check_attach calls wait_task_inactive to ensure that the target thread has finished switching out. Hence, after ptrace_check_attach and before the current thread might possibly die or do PTRACE_DETACH, it is safe to access thread_struct without race concerns, modulo SIGKILL. (This is the basis of the ptrace implementation's own safe thread register access.) If I understand you correctly, perfmon2 has a user-mode component that uses ptrace on a thread of interest to get it stopped, and then the same ptrace'ing thread calls into a kernel-mode component that uses ptrace_check_attach to validate that its caller really did the right ptrace synchronization. Is that correct? The semantics of ptrace in this area are unchanged in the utrace-based implementation. The internal details differ. If you are looking for a way in utrace-based kernels to support the same user-mode component's use of ptrace with the same ptrace-based validation in the kernel-mode component, that is straightforward. Rather than calling ptrace_check_attach, you can just call sys_ptrace with a no-op request like PTRACE_GETEVENTMSG, or even an invalid request like -1, instead of calling into ptrace internals. The ptrace_check_attach work is done before the request is checked. If sys_ptrace returns -EIO instead of -ESRCH, the synchronization check passed. This should work the same in any kernel. If you are looking for a new utrace-based means to achieve the same safety for accessing thread state, I can help you figure that out too. utrace is a kernel API for building new facilities, it is not itself a new user-level facility. As yet there is no canonical new thing built on utrace, other than ptrace. If you are using ptrace solely for this purpose and no other, then you don't need any user-level facility at all. You can just do it all directly in your kernel component using a few utrace calls. I can go into the details with someone who is interested in implementing it. Thanks, Roland _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
