All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen.5i5j@gmail.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.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 08:18:47 +0800	[thread overview]
Message-ID: <52F18367.2060803@gmail.com> (raw)
In-Reply-To: <52F109AF.8040800@hitachi.com>

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.

 - 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

  reply	other threads:[~2014-02-05  0:18 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
2014-02-05  0:18                     ` Chen Gang [this message]
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=52F18367.2060803@gmail.com \
    --to=gang.chen.5i5j@gmail.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=egtvedt@samfundet.no \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --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.