similar to: [PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > +#ifdef CONFIG_KPROBES > +/* > + * Blacklist ganerating macro. Specify functions which is not probed > + * by using this macro. > + */ > +#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr =

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > +#ifdef CONFIG_KPROBES > +/* > + * Blacklist ganerating macro. Specify functions which is not probed > + * by using this macro. > + */ > +#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr =

(2013/11/11 20:16), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> Currently the blacklist is maintained by hand in kprobes.c >> which is separated from the function definition and is hard >> to catch up the kernel update. >> To solve this issue, I've tried to implement new >> NOKPROBE_SYMBOL() macro

(2013/11/11 20:16), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> Currently the blacklist is maintained by hand in kprobes.c >> which is separated from the function definition and is hard >> to catch up the kernel update. >> To solve this issue, I've tried to implement new >> NOKPROBE_SYMBOL() macro

On Wed, Nov 20, 2013 at 04:22:21AM +0000, Masami Hiramatsu wrote: > Use NOKPROBE_SYMBOL macro to protect functions from kprobes > instead of __kprobes annotation in trap.c. > This also applies __always_inline annotation for some cases, > because NOKPROBE_SYMBOL() will inhibit inlining by referring > the symbol address. NOKPROBE_SYMBOL seems to add a reference from some variable to

On Wed, Nov 20, 2013 at 04:22:21AM +0000, Masami Hiramatsu wrote: > Use NOKPROBE_SYMBOL macro to protect functions from kprobes > instead of __kprobes annotation in trap.c. > This also applies __always_inline annotation for some cases, > because NOKPROBE_SYMBOL() will inhibit inlining by referring > the symbol address. NOKPROBE_SYMBOL seems to add a reference from some variable to

Introduce NOKPROBE_SYMBOL() macro which builds a kprobe blacklist in build time. The usage of this macro is similar to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just after the function definition. If CONFIG_KPROBES=y, the macro is expanded to the definition of a static data structure of kprobe_blackpoint which is initialized for the function and put the address of the data structure

(2013/11/22 11:35), Masami Hiramatsu wrote: > (2013/11/21 16:29), Ingo Molnar wrote: >> >> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >> >>> (2013/11/21 2:36), Frank Ch. Eigler wrote: >> >> [ ... ] >>>> one needs to resort to something like: >>>> >>>> # cat /proc/kallsyms | grep ' [tT] '

(2013/11/22 11:35), Masami Hiramatsu wrote: > (2013/11/21 16:29), Ingo Molnar wrote: >> >> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >> >>> (2013/11/21 2:36), Frank Ch. Eigler wrote: >> >> [ ... ] >>>> one needs to resort to something like: >>>> >>>> # cat /proc/kallsyms | grep ' [tT] '

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > Use NOKPROBE_SYMBOL macro for protecting functions > from kprobes instead of __kprobes annotation in > dumpstack.c. > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> > Cc: Thomas Gleixner <tglx at linutronix.de> > Cc: Ingo Molnar <mingo at redhat.com> > Cc:

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > Use NOKPROBE_SYMBOL macro for protecting functions > from kprobes instead of __kprobes annotation in > dumpstack.c. > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> > Cc: Thomas Gleixner <tglx at linutronix.de> > Cc: Ingo Molnar <mingo at redhat.com> > Cc:

(2013/11/27 22:30), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> (2013/11/22 11:35), Masami Hiramatsu wrote: >>> (2013/11/21 16:29), Ingo Molnar wrote: >>>> >>>> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >>>> >>>>> (2013/11/21 2:36), Frank Ch.

(2013/11/27 22:30), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> (2013/11/22 11:35), Masami Hiramatsu wrote: >>> (2013/11/21 16:29), Ingo Molnar wrote: >>>> >>>> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >>>> >>>>> (2013/11/21 2:36), Frank Ch.

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > (2013/11/21 2:36), Frank Ch. Eigler wrote: [ ... ] > > one needs to resort to something like: > > > > # cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do > > perf probe $symbol > > done > > > > then wait for a few hours for that to finish. Then, or

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > (2013/11/21 2:36), Frank Ch. Eigler wrote: [ ... ] > > one needs to resort to something like: > > > > # cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do > > perf probe $symbol > > done > > > > then wait for a few hours for that to finish. Then, or

Hi - > > Does this new blacklist cover enough that the kernel now survives a > > broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms? > > That's generally the purpose of the annotations - if it doesn't then > that's a bug. AFAIK, no kernel since kprobes was introduced has ever stood up to that test. perf probe lacks the wildcarding powers of