search for: nokprobe_symbol

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 va...

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 va...

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 replaces __kprobes with NOKPROBE_SYMBOL() macro or apply __always_inline annotation for some cases, because NOKPROBE_SYMBOL(...

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 replaces __kprobes with NOKPROBE_SYMBOL() macro or apply __always_inline annotation for some cases, because NOKPROBE_SYMBOL(...

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 (as like as EXPORT_SYMBOL), it is easy to maintain. This series replaces __kprobes with NOKPROBE_SYMBOL() macro or apply __always_inline annotation for some cases...

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 (as like as EXPORT_SYMBOL), it is easy to maintain. This series replaces __kprobes with NOKPROBE_SYMBOL() macro or apply __always_inline annotation for some cases...

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. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com&gt...

* 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 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. > At this moment, I applied the macro only for the symbols > which is listed in kprobes.c. As we discussed in previous &g...

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: "H. Peter Anvin" <hp...

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. At this moment, I applied the macro only for the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc acc...

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. At this moment, I applied the macro only for the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc acc...

(2013/11/23 6:21), Andi Kleen wrote: > 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 ad...

...asami.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 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. >> At this moment, I applied the macro only for the symbols >> which is listed in kprobes.c. As we discusse...

...asami.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 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. >> At this moment, I applied the macro only for the symbols >> which is listed in kprobes.c. As we discusse...

* 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...

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...

...t; - trace_graph_return > - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk > - This list still be not perfect. I just enabled/disabled kprobes > one by one. There might be combined bugs (combination of several > kprobes). > - Some of them are hard to specify by NOKPROBE_SYMBOL because they are > defined in assembly file. > > Anyway, to fix all of them, I think we need file-based blacklist > especially for assembler symbols. assembler symbols shouldn't be particular hard either, just put them into the noprobes section. > For example, we can get a...

...trace_hardirqs_off_thunk, trace_hardirqs_on_thunk > >> - This list still be not perfect. I just enabled/disabled kprobes > >> one by one. There might be combined bugs (combination of several > >> kprobes). > >> - Some of them are hard to specify by NOKPROBE_SYMBOL because they are > >> defined in assembly file. > >> > >> Anyway, to fix all of them, I think we need file-based blacklist > >> especially for assembler symbols. > > > > assembler symbols shouldn't be particular hard either, just put them &gt...

...d to be clear) - restore - trace_graph_return - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk - This list still be not perfect. I just enabled/disabled kprobes one by one. There might be combined bugs (combination of several kprobes). - Some of them are hard to specify by NOKPROBE_SYMBOL because they are defined in assembly file. Anyway, to fix all of them, I think we need file-based blacklist especially for assembler symbols. For example, we can get all text symbols by below command; nm some-file.o | grep -i " t " | cut -f3 -d" " so that we can make a bla...