lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 Apr 2008 08:46:44 +0200 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: "Frank Ch. Eigler" <fche@...hat.com> Cc: prasad@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...e.hu, mathieu.desnoyers@...ymtl.ca Subject: Re: [RFC PATCH 1/2] Marker probes in futex.c On Thu, 2008-04-17 at 18:02 -0400, Frank Ch. Eigler wrote: > Peter Zijlstra <a.p.zijlstra@...llo.nl> writes: > > > [...] > >> If we were to log just the futex_ops, just as you had suggested, > >> "Just log: > >> > >> futex: <uaddr> wait > >> futex: <uaddr> wakeup" > >> [...] > >> If you can specifically point me to information you think would be > >> absolutely unnecessary, I can get them out of the trace_mark(). > > > > I'm thinking everything is superflous; you're basically logging what > > strace already gives you > > But we don't want to run strace just for this stuff. As you probably > know, strace involves invasive user-space context-switching between > the target and the tracer. > > > except worse by encoding local variable names and exposing kernel > > pointers. > > The pointers are probably excessive, the and the names don't really > matter. Then what do we do when someone comes along and changes one of those names; do we go around changing the markers and then requiring all tools to change as well? (And no this isn't far fetched; I'm thinking of changing fshared in the near future). Sounds like people will complain and generate back pressure against such changes - something we should avoid. As soon as these markers place a significant burden on code maintenance I'm against it. > What does matter is providing enough information for a > problem diagnosis tool & person to reconstruct what the kernel must > have been thinking when it did something noteworthy. Sure, but then just make a strace like tracer and be done with it - no need to pollute the futex code with that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists