Messages in this thread | | | Date | Wed, 26 Aug 2009 13:08:12 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 08/12] add trace events for each syscall entry/exit |
| |
* Peter Zijlstra (peterz@infradead.org) wrote: > On Tue, 2009-08-25 at 14:31 -0400, Mathieu Desnoyers wrote: > > > (Well, I do not have time currently to look into the gory details > > (sorry), but let's try to take a step back from the problem.) > > > > The design proposal for this kthread behavior wrt syscalls is based on a > > very specific and current kernel behavior, that may happen to change and > > that I have actually seen proven incorrect. For instance, some > > proprietary Linux driver does very odd things with system calls within > > kernel threads, like invoking them with int 0x80. > > > > Yes, this is odd, but do we really want to tie the tracer that much to > > the actual OS implementation specificities ? > > > > That sounds like a recipe for endless breakages and missing bits of > > instrumentation. > > > > So my advice would be: if we want to trace the syscall entry/exit paths, > > let's trace them for the _whole_ system, and find ways to make it work > > for corner-cases rather than finding clever ways to diminish > > instrumentation coverage. > > > > Given the ret from fork example happens to be the first event fired > > after the thread is created, we should be able to deal with this problem > > by initializing the thread structure used by syscall exit tracing to an > > initial "ret from fork" value. > > So you're saying we should let proprietary crap influence the design of > the kernel in any way?
Nah. And I start to feel comfortable with syscall entry/exit being only be traced for userspace threads. But as I pointed out in a follow-up email, the lack of sys_*() tracing for invocation from within the kernel might be problematic. This is actually my main point.
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |