Messages in this thread | | | Date | Wed, 06 Nov 2013 19:34:56 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text |
| |
(2013/11/06 15:07), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote: > >>>> [...] I hope to build the list when the kernel build time if >>>> possible... Would you have any idea to classify some annotated(but no >>>> side-effect) functions? >>> >>> The macro magic I can think of would need to change the syntax of the >>> function definition - for example that is how the SYSCALL_DEFINE*() >>> macros work. >> >> Would you mean something like the below macro? :) >> >> NOKPROBE_SYMBOL(int, func_ptr_is_kernel_text)(void *ptr) > > I think this is rather ugly and harder to maintain. The whole _point_ of > such annotations is to make them 'easy on the eyes', to make it easy to > skip a 'noinline', 'noprobe' or 'notrace' tag. > > Using something like NOKPROBE_SYMBOL() makes the whole construct ugly and > attention seeking.
Hmm, by the way how about Steven's idea? A macro like EXPORT_SYMBOL? At least for kprobes_blacklist, which is defined/maintained in kprobes.c for some symbols(*), that is useful for updating it because we can put it near the function definition.
* These symbols can not moves to other section because it already in a different section.
Of course, still this is not a big problem since there are a few symbols in the kprobe_blacklist.
> So until compilers get smarter (or there's some compiler trick I haven't > noticed) lets stay with the separate section - it's not the end of the > world, the (effective) 'noinline' aspect of noprobes changes code > generation anyway.
I see. :)
So, would you pull this series ? Or I need any update?
Thank you,
-- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |