Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementationto CONFIG_KRETPROBES enabled area

[Masami Hiramatsu]

(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@xxxxxxxxx>
>>>>>>> ---
>>>>>>>  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@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/