Stephane Eranian wrote:
Kevin,
On Mon, Jul 09, 2007 at 10:58:37AM -0500, Kevin Corry wrote:
Back in January there was a thread about Perfmon not working on Fedora Core 7
kernels due to the switch from ptrace to utrace.
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/2007-January/001183.html
I've just found out that the project I'm working on will be using the Fedora
Core 7 kernel as a base, so I was wondering if there had been any conclusions
about how Perfmon would handle this change.
To review, when using a non-self-monitored per-process context, Perfmon uses
the ptrace_check_attach() call to verify that the monitoring process has
ptraced the monitored process and that the monitored process is not actively
using one of the CPUs. However, with the utrace changes in FC7, the
ptrace_check_attach() routine has been removed. So here are a few questions:
Yes, I remember this discussion with Will. Not sure if he (or Roland) ever found
a solution to this. But let me describe why we use ptrace as I think it could
be useful for the utrace discussion.
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.
<snip>
Some key properties of ptrace that we rely upon:
* a thread can only by ptraced by one other process
* only the ptracer process can issue ptrace commands on the ptraced
thread
With utrace multiple engines can attach to the same thread. Maybe it would be
possible to do this work with in a utrace engine to avoid SIGCONT problem below.
Those two propperties ensure that when the thread is stopped, and we are in the
middle
of a perfmon operation on it, the thread cannot be woken up. If we were to use
plain
SIGTOP, then you could use a kill SIGCONT to wake the thread up. I don't think
this solution covers alls risks at 100% but this is the best I could find.
1) Does utrace provide anything similar to ptrace_check_attach(). For now I'm
assuming it doesn't, since nothing was mentioned in the earlier postings. Are
there any other kernel APIs the Perfmon could use that would accomplish the
same or similar behavior? We're basically trying to ensure that the monitored
process does not get scheduled during the running of the effected Perfmon
system-calls, and that the controlling process has permission to access the
controlled process. Is there anything that I'm missing?
Don't know about that? I would think that the functionality provided by
ptrace_check_attach() would still be needed for utrace.
2) If we know for certain that a user-space tool always ptrace's the monitored
process before making any of the effected Perfmon system-calls, then the
ptrace_check_attach() call in the kernel should always be successful. In this
case, could the call to ptrace_check_attach() be removed without altering the
overall behavior? Obviously this isn't the real solution, but it might be a
temporary workaround.
Remember that this is a kernel API. We cannot assume tools are well-behaved.
There may be bugs and we need to prevent any malicious usage.
3) What's the worst-case scenario if the Perfmon system-calls were run without
ptracing the monitored process? Could it corrupt kernel data? Crash the
machine? Would it just result in erroneous data from the Perfmon
system-calls?
This is a good question.
You'd still have the spinlock protecting access by multiple threads at the same
time. So you'd still have some consistency there. But there would be silent
corruption. Imagine the monitored thread (thread0) is running on CPU0, and you
come in
on CPU1 to re-write thread0 PMC registers. You would not be able to touch
thread0's
actual registers. So you would come back from the syscall thinking you have
changed
the event being mesaured when in fact you would not, at least until the next
context
switch.
4) Will utrace eventually replace ptrace in the mainline kernel? I found some
discussions about utrace on lkml, and it seems like its getting some positive
feedback. But it doesn't look like it's been submitted in full for inclusion,
so I'm not sure what kind of time-line we're talking about. If it does get
merged, obviously we'll need to find a real solution for Perfmon at some
point.
There was a presentation about utrace/uprobes at OLS. It seems utrace went into
the -mm tree but then it was pulled because of instability. We could check
with Roland/Will for a status update.
I'll probably need to ask some of these questions on lkml as well, but I
figured you guys might have a bit of insight on the issue already.
Unfortunately, I have not used utrace yet.
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
