All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: ananth@in.ibm.com, anil.s.keshavamurthy@intel.com,
	"Håvard Skinnemoen" <hskinnemoen@gmail.com>,
	"David Miller" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hans-Christian Egtvedt" <egtvedt@samfundet.no>,
	"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>,
	"Ingo Molnar" <mingo@elte.hu>
Subject: Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area
Date: Wed, 05 Feb 2014 00:39:27 +0900	[thread overview]
Message-ID: <52F109AF.8040800@hitachi.com> (raw)
In-Reply-To: <52F0F0ED.5090005@gmail.com>

(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.
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@hitachi.com



  reply	other threads:[~2014-02-04 15:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01 12:17 [PATCH] kernel/kprobes.c: move cleanup_rp_inst() to where CONFIG_KRETPROBES enabled Chen Gang
2014-02-02  2:40 ` Masami Hiramatsu
2014-02-03 11:48   ` Chen Gang
2014-02-03 15:42     ` Masami Hiramatsu
2014-02-04  2:25       ` Chen Gang
2014-02-04  5:16         ` [PATCH] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area Chen Gang
2014-02-04  7:17           ` Masami Hiramatsu
2014-02-04 11:58             ` Chen Gang
2014-02-04 12:07             ` Chen Gang
2014-02-04 13:29               ` Masami Hiramatsu
2014-02-04 13:53                 ` Chen Gang
2014-02-04 15:39                   ` Masami Hiramatsu [this message]
2014-02-05  0:18                     ` Chen Gang
2014-02-05  1:21                       ` Masami Hiramatsu
2014-02-05  3:08                         ` Chen Gang
2014-02-05  3:36                           ` [PATCH] kernel/kprobes.c: move kretprobe implementation to CONFIG_KRETPROBES area Chen Gang
2014-02-05  5:00                             ` Masami Hiramatsu
2014-02-05  5:08                               ` Chen Gang
2014-02-05  5:27                               ` [PATCH] include/linux/kprobes.h: move all functions to their matched area Chen Gang
2014-02-05  7:51                                 ` Masami Hiramatsu
2014-02-05 11:12                                   ` Chen Gang
2014-02-05  4:57                           ` [PATCH] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area Masami Hiramatsu
2014-02-05  5:13                             ` Chen Gang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F109AF.8040800@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=egtvedt@samfundet.no \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.