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

[Chen Gang]

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.

 - And original kprobe static inline functions have done like that,
   in same header file, if no obvious reasons, we can try to follow.


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


> Thank you,
> 

Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
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/