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.
In per-thread mode, you cannot access the PMU state of another thread when it
is still running. To peek and poke the PMU state, the thread needs to be off
any CPU. So you have to somehow stop a thread. You have 2 solutions
* send a SIGSTOP
* attach to the thread with ptrace() (which actually sends a SIGSTOP)
Perfmon forces user level tools to use ptrace() to stop the thread. As such,
many of the perfmon calls which do need PMU state access check that the
monitored
thread is actually ptraced. Note that this restrictions is lifted when the
perfmon context is not LOADED (attached). Self-monitoring thread are exempt
for those restrictions.
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
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.
--
-Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
