Messages in this thread | | | Date | Wed, 05 Feb 2014 10:21:39 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area |
| |
(2014/02/05 9:18), Chen Gang wrote: > On 02/04/2014 11:39 PM, Masami Hiramatsu wrote: >> (2014/02/04 22:53), Chen Gang wrote: >>> On 02/04/2014 09:29 PM, Masami Hiramatsu wrote: >>>> (2014/02/04 21:07), Chen Gang wrote: >>>>> On 02/04/2014 03:17 PM, Masami Hiramatsu wrote: >>>>>> (2014/02/04 14:16), Chen Gang wrote: >>>>>>> When CONFIG_KRETPROBES disabled, all *kretprobe* generic implementation >>>>>>> are useless, so need move them to CONFIG_KPROBES enabled area. >>>>>>> >>>>>>> Now, *kretprobe* generic implementation are all implemented in 2 files: >>>>>>> >>>>>>> - in "include/linux/kprobes.h": >>>>>>> >>>>>>> move inline kretprobe*() to CONFIG_KPROBES area and dummy outside. >>>>>>> move some *kprobe() declarations which kretprobe*() call, to front. >>>>>>> not touch kretprobe_blacklist[] which is architecture's variable. >>>>>>> >>>>>>> - in "kernel/kprobes.c": >>>>>>> >>>>>>> move all kretprobe* to CONFIG_KPROBES area and dummy outside. >>>>>>> define kretprobe_flush_task() to let kprobe_flush_task() call. >>>>>>> define init_kretprobes() to let init_kprobes() call. >>>>>>> >>>>>>> The patch passes compiling (get "kernel/kprobes.o" and "kernel/built- >>>>>>> in.o") under avr32 and x86_64 allmodconfig, and passes building (get >>>>>>> bzImage and Modpost modules) under x86_64 defconfig. >>>>>> >>>>>> Thanks for the fix! and I have some comments below. >>>>>> >>>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> >>>>>>> --- >>>>>>> include/linux/kprobes.h | 58 +++++---- >>>>>>> kernel/kprobes.c | 328 +++++++++++++++++++++++++++--------------------- >>>>>>> 2 files changed, 222 insertions(+), 164 deletions(-) >>>>>>> >>>>>>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h >>>>>>> index 925eaf2..c0d1212 100644 >>>>>>> --- a/include/linux/kprobes.h >>>>>>> +++ b/include/linux/kprobes.h >>>>>>> @@ -223,10 +223,36 @@ static inline int kprobes_built_in(void) >>>>>>> return 1; >>>>>>> } >>>>>>> >>>>>>> +int disable_kprobe(struct kprobe *kp); >>>>>>> +int enable_kprobe(struct kprobe *kp); >>>>>>> + >>>>>>> +void dump_kprobe(struct kprobe *kp); >>>>>>> + >>>>>>> +extern struct kretprobe_blackpoint kretprobe_blacklist[]; >>>>>>> + >>>>>>> #ifdef CONFIG_KRETPROBES >>>>>>> extern void arch_prepare_kretprobe(struct kretprobe_instance *ri, >>>>>>> struct pt_regs *regs); >>>>>>> extern int arch_trampoline_kprobe(struct kprobe *p); >>>>>>> +static inline void kretprobe_assert(struct kretprobe_instance *ri, >>>>>>> + unsigned long orig_ret_address, unsigned long trampoline_address) >>>>>>> +{ >>>>>>> + if (!orig_ret_address || (orig_ret_address == trampoline_address)) { >>>>>>> + printk(KERN_ERR >>>>>>> + "kretprobe BUG!: Processing kretprobe %p @ %p\n", >>>>>>> + ri->rp, ri->rp->kp.addr); >>>>>>> + BUG(); >>>>>>> + } >>>>>>> +} >>>>>>> +static inline int disable_kretprobe(struct kretprobe *rp) >>>>>>> +{ >>>>>>> + return disable_kprobe(&rp->kp); >>>>>>> +} >>>>>>> +static inline int enable_kretprobe(struct kretprobe *rp) >>>>>>> +{ >>>>>>> + return enable_kprobe(&rp->kp); >>>>>>> +} >>>>>>> + >>>>>>> #else /* CONFIG_KRETPROBES */ >>>>>>> static inline void arch_prepare_kretprobe(struct kretprobe *rp, >>>>>>> struct pt_regs *regs) >>>>>>> @@ -236,19 +262,20 @@ static inline int arch_trampoline_kprobe(struct kprobe *p) >>>>>>> { >>>>>>> return 0; >>>>>>> } >>>>>>> -#endif /* CONFIG_KRETPROBES */ >>>>>>> - >>>>>>> -extern struct kretprobe_blackpoint kretprobe_blacklist[]; >>>>>>> - >>>>>>> static inline void kretprobe_assert(struct kretprobe_instance *ri, >>>>>>> unsigned long orig_ret_address, unsigned long trampoline_address) >>>>>>> { >>>>>>> - if (!orig_ret_address || (orig_ret_address == trampoline_address)) { >>>>>>> - printk("kretprobe BUG!: Processing kretprobe %p @ %p\n", >>>>>>> - ri->rp, ri->rp->kp.addr); >>>>>>> - BUG(); >>>>>>> - } >>>>>>> } >>>>>>> +static inline int disable_kretprobe(struct kretprobe *rp) >>>>>>> +{ >>>>>>> + return 0; >>>>>>> +} >>>>>>> +static inline int enable_kretprobe(struct kretprobe *rp) >>>>>>> +{ >>>>>>> + return 0; >>>>>>> +} >>>>>> >>>>>> No, these should returns -EINVAL or -ENOSYS, since these are user API. >>>>> >>>>> OK, thanks, it sounds reasonable to me. >>>>> >>>>>> Anyway, I don't think those inlined functions to be changed, because >>>>>> most of them are internal functions. If CONFIG_KRETPROBES=n, it just >>>>>> be ignored. >>>>>> >>>>> >>>>> In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(), >>>>> disable_kretprobe(), and enable_kretprobe() are not ignored. >>>> >>>> Really? where are they called? I mean, those functions do not have >>>> any instance unless your module uses it (but that is not what the kernel >>>> itself should help). >>>> >>> >>> If what you said correct (I guess so), for me, we still need let them in >>> CONFIG_KRETPROBES area, and without any dummy outside, just like another >>> *kprobe* static inline functions have done in "include/linux/kprobes.h". >> >> kretprobe_assert() is only for the internal check. So we don't need to care >> about, and disable/enable_kretprobe() are anyway returns -EINVAL because >> kretprobe can not be registered. And all of them are inlined functions. >> In that case, we don't need to care about it. > > Hmm... it is related with code 'consistency': > > - these static inline functions are kretprobe generic implementation, > and we are trying to let all kretprobe generic implementation within > CONFIG_KRETPROBES area.
No, actually, kretprobe is just built on the kprobe. enable/disable_kretprobe just wrapped the kprobe methods. And kretprobe_assert() is just for kretprobe internal use. that is not an API. Moving only the kretprobe_assert() into the CONFIG_KRETPROBE area is not bad, but since it is just a static inline function, if there is no caller, it just be ignored, no side effect.
> > - And original kprobe static inline functions have done like that, > in same header file, if no obvious reasons, we can try to follow.
It is no reasons to follow that too. Please keep your patch simple as much as possible.
>> I just concerned that it is a waste of memory if there are useless kretprobe >> related instances are built when CONFIG_KRETPROBES=n. >> > > Yeah, that is also one of reason (3rd reason). > > > And if necessary, please help check what we have done whether already > "let all kretprobe generic implementation within CONFIG_KRETPROBES area" > (exclude declaration, struct/union definition, and architecture > implementation).
As I commented, your changes in kernel/kprobes.c are good to me except two functions. That's all what we need to fix :)
Thank you!
-- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |