Will, On Tue, Jul 10, 2007 at 09:43:54AM -0400, William Cohen wrote: > 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. > Yes, ptrace is used to force a thread stop, and thus a state flush. Now with utrace, I don't quite understand how such a sequence woule not be needed if I want to peek at the user state of a thread (e.g., PEEKUSER).
Perfmon does have a per-thred save-area where the last PMU state is saved on context switch for instance. The issue is with the interface guarantee you provide to user tools. With the approach where you do not touch actual hardware, you cannot make any guarantee to user. Imagine pfm_start(), today we can say that when you come back from the call, we guarantee that the next time the monitored threads runs, it will have monitoring active. Without the stop/flush, that guarantee is gone. All you can say now is that eventually monitoring will become active, probably not before the next context switch or so. > <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. > I don't know enough about utrace, but one thing I am worried about is the fact that one can use kernel modules to implement certain functionalities using the utrace infrastructure. Does this mean that I would need to be root to get access to certain functionalities? Thanks. > > > >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/ -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
