utrace and perfmon2

[stephane eranian]

Maynard,

On Feb 19, 2008 12:01 AM, Maynard Johnson <maynardj at us.ibm.com> wrote:
>
> stephane eranian wrote:
> > Maynard,
> >
> >
> > On Feb 16, 2008 1:07 AM, Maynard Johnson <maynardj at us.ibm.com> wrote:
> >
> >> Hi,
> >> I have a requirement to build a kernel with both utrace and perfmon2
> >> patches.  I'm using kernel version 2.6.24.  Since neither of these
> >> features are accepted upstream yet (well, Jim Keniston tells me that
> >> some initial pieces of utrace have been accepted), the patches don't
> >> play nicely with one another.  The patches apply OK, but I get a compile
> >> failure in perfmon/perfmon_syscalls.c because it's trying to use the
> >> function ptrace_check_attach (removed by the utrace patch).  A separate
> >> note is being sent to the perfmon2 maintainer to see if he might help,
> >> but I thought I'd post here as well, in case someone has gone into this
> >> territory already.
> >>
> >>
> > I have responded to the other message. Currently, all the perfmon code
> > needs is an equivalent to ptrack_check_attach(). I assume that a utrace
> > kernel emulates the user level PTRACE interface.
> >
> Stephane, correct me if I'm wrong, but it seems that the main purpose of
> perfmon's use of ptrace_check_attach is to make sure the traced process
> is stopped.  If that is true, perhaps all that's needed is to call the
> utrace function to stop the traced process -- utrace_set_flags with
> UTRACE_ACTION_QUIESCE.
>

Yes, I think that with utrace it would be easier to do this. Today, there is a
user-visible requirement that the application needs to use ptrace() to
stop the thread monitor/to monitor thread. With utrace, we could lift that
restriction and have the kernel do it. The main motivation is to ensure
the thread is OFF the cpu so that its PMU state can be changed safely.
Ptrace is overkill, especially if the thread remains ptrace'd during the
entire run and not just when we need to issue a perfmon syscall.

However, there are some key properties of ptrace which we relay upon:
   1/ there can only be one ptracer
   2/ a thread stopped by ptrace can only be woken up by the ptracing parent

2/ is particularly important, it guarantees that no other process could wakeup
 the stopped thread, even by sending a SIGCONT. This is necessary to avoid
 thread being awaken while they are being operated on by perfmon. OTOH,
given that we hold a per session locked while doing so AND that this lock
is also grabbed on context switch in, the risk does not really exists, at least
for the PMU state.