similar to: [PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist

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

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

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

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

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

(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

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

* 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/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] '

(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

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the