Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH 08/12] add trace events for each syscall entry/exit | From | Peter Zijlstra <> | Date | Wed, 26 Aug 2009 08:48:07 +0200 |
| |
On Tue, 2009-08-25 at 21:42 +0200, Frederic Weisbecker wrote: > On Tue, Aug 25, 2009 at 02:31:19PM -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 ? > > > I really can't see the point in doing this. I don't expect the kernel > behaviour to change soon and have explicit syscalls interrupts done > from it. It's not about a current kernel implementation fashion, > it's about kernel design sanity that is not likely to go backward. > > Is it worth it to trace kernel threads, maintain their tracing > specificities (such as workarounds with ret_from_fork that implies) > just because we want to support tracing on some silly proprietary drivers? > > > > > > 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. > > > If developers of out of tree drivers want to implement buggy things > that would never be accepted after a minimal review here, and then instrument > their bugs, then I would suggest them to implement their own ad hoc instrumentation, > really :-/ > > What's the point in supporting out of tree bugs? > > Well, the only advantage of doing this would be to support reverse engineering > in tiny and rare corner cases. Not that worth the effort. > > > > 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. > > > > Mathieu > > > It means we have to support and check this corner case in every archs > that support syscall tracing, deal with crashes because we omitted it, etc... > > For all the things I've explained above I don't think it's worth the effort. > > But it's just my opinion...
I fully agree, let out of tree people deal with their own crap.
| ![\](/images/icornerr.gif) |