| 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: Tue, 06 Nov 2007 14:36:29 -0800 From: Mike Mason <mmlnx@...ibm.com> To: Mathieu Desnoyers <compudj@...stal.dyndns.org> Cc: ltt-dev@...fik.org, linux-kernel@...r.kernel.org, systemtap@...rces.redhat.com Subject: Re: [to-be-posted-soon] Multiple handlers per marker Mathieu Desnoyers wrote: > * Mike Mason (mmlnx@...ibm.com) wrote: >> Mathieu Desnoyers wrote: >>> * Mathieu Desnoyers (compudj@...stal.dyndns.org) wrote: >>>> * Mathieu Desnoyers (mathieu.desnoyers@...ymtl.ca) wrote: >>>>> * Mike Mason (mmlnx@...ibm.com) wrote: >>>>>> Hi Mathieu, >>>>>> >>>>>> Are you aware of any working being done to allow multiple handlers to >>>>>> be attached to a marker? Something like what kprobes allows. I've >>>>>> started to look into this and don't want to duplicate efforts. >>>>>> >>>>> Nope, but I know we will have to address this. >>>>> >>>>> Something along the lines of walking an RCU list of function pointers, >>>>> calling them. >>>>> >>>>> The only downside I see is that we will have to pass a va_list * instead >>>>> of real va args. The could make the marker site a little bit bigger and >>>>> will change the probe callback arguments. >>>>> >>>>> What do you think about these ideas ? >>>>> >>>>> If we can find a way to make the common case (only one probe connected) >>>>> _ultra_ fast, and yet architecture independent, that would be awesome. A >>>>> simple call is kind of hard to beat though.. So we may have to think >>>>> about a design with : >>>>> >>>>> - One call at the marker site >>>>> - if 1 probe is installed : >>>>> - If the format string is empty, connect a probe without va args. >>>>> - If the format string is not empty, connect a "stage 1" probe that >>>>> takes >>>>> the va args, starts/ends the va_list and calls _one_ function (let's >>>>> call it "stage 2" probe), that takes va_list as parameter. >>>>> - if more than 1 probe is installed : >>>>> - The stage 1 probe creates the va_list and passes it to each function >>>>> connected, iterated with an RCU list. >>>>> >>>>> What do you think ? >>>>> >>>>> Mathieu >>>>> >>>> I'm working on an implementation. >>>> >>> It's ready for testing. Please grab >>> http://ltt.polymtl.ca/lttng/patch-2.6.24-rc1-git13-lttng-0.10-pre18.tar.bz2 >>> patch name : >>> markers-support-multiple-probes.patch >> This patch alone doesn't apply cleanly at all on 2.6.24-rc1-git14. Are >> there other patches in this series I should apply first? >> > > Yes, the following ones should suffice : > > # instrumentation menu removal > add-kconfig-to-arch.patch > add-arch-supports-oprofile.patch > add-arch-supports-kprobes.patch > move-kconfig-instrumentation-to-arch.patch > # > kprobes-use-mutex-for-insn-pages.patch > kprobes-dont-use-kprobes-mutex-in-arch-code.patch > kprobes-declare-kprobes-mutex-static.patch > declare-array.patch > text-edit-lock-architecture-independent-code.patch > text-edit-lock-alternative-i386-and-x86_64.patch > text-edit-lock-kprobes-architecture-independent.patch > text-edit-lock-kprobes-i386.patch > text-edit-lock-kprobes-x86_64.patch > text-edit-lock-i386-standardize-debug-rodata.patch > text-edit-lock-x86_64-standardize-debug-rodata.patch > # > immediate-values-architecture-independent-code.patch > immediate-values-kconfig-embedded.patch > immediate-values-move-kprobes-i386-restore-interrupt-to-kdebug-h.patch > add-asm-compat-to-x86.patch > immediate-values-i386-optimization.patch > immediate-values-powerpc-optimization.patch > immediate-values-documentation.patch > # > linux-kernel-markers-immediate-values.patch > # > markers-support-multiple-probes.patch > > Tell me if you still have rejects. I applied the above patches to 2.6.24-rc1-git14. They applied fine with just a few offsets until the last patch, which yielded this result: patching file include/linux/marker.h Hunk #5 succeeded at 162 with fuzz 2. patching file kernel/marker.c Hunk #14 FAILED at 534. Hunk #15 FAILED at 587. Hunk #16 FAILED at 621. Hunk #17 FAILED at 732. Hunk #18 FAILED at 769. Hunk #19 succeeded at 791 (offset 12 lines). 5 out of 19 hunks FAILED -- saving rejects to file kernel/marker.c.rej patching file kernel/module.c Hunk #1 succeeded at 1998 (offset -3 lines). Hunk #2 succeeded at 2608 (offset -37 lines). Hunk #3 succeeded at 2651 with fuzz 1 (offset -3 lines). patching file include/linux/module.h Hunk #1 FAILED at 468. Hunk #2 succeeded at 572 (offset -2 lines). 1 out of 2 hunks FAILED -- saving rejects to file include/linux/module.h.rej patching file samples/markers/probe-example.c Mike > > Mathieu > > >> Mike >> >>> It still need to go through patchcheck.pl and some polishing, but it >>> seems to work fine for me with multiple probes (the sample marker, >>> sample probe and multiple instances of my lttng probes can >>> connect/disconnect without problem). >>> Currently, the "connect/disconnect" and "arm/disarm" operations are >>> separate. However, they could be merged. Any comment/preference on this? >>> Being separate, a probe provider can wait until the very last moment >>> before it activates its markers, with a minimalistic impact on the >>> system, but it is not such a strong argument. >>> Mathieu > - 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