Date:	Wed, 05 Feb 2014 00:39:27 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Chen Gang <gang.chen.5i5j@...il.com>
Cc:	ananth@...ibm.com, anil.s.keshavamurthy@...el.com,
	Håvard Skinnemoen 
	<hskinnemoen@...il.com>, David Miller <davem@...emloft.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementation
 to CONFIG_KRETPROBES enabled area

(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@...il.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.
I just concerned that it is a waste of memory if there are useless kretprobe
related instances are built when CONFIG_KRETPROBES=n.

Thank you,

>>>
>>>> So, I think you don't need to change kprobes.h.
>>>>
>>>
>>> So "kprobes.h" still need be changed.
>>
>> Is there any concrete problem you have?
>>
> 
> No, I just read the code, no additional really issues.
> 
> 
> Thanks.
> 


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


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

Powered by blists - more mailing lists