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>
Subject: Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area
Date: Tue, 04 Feb 2014 20:07:15 +0800 [thread overview]
Message-ID: <52F0D7F3.7000901@gmail.com> (raw)
In-Reply-To: <52F09404.3060502@hitachi.com>
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.
> So, I think you don't need to change kprobes.h.
>
So "kprobes.h" still need be changed.
>> +
>> +#endif /* CONFIG_KRETPROBES */
>>
>> #ifdef CONFIG_KPROBES_SANITY_TEST
>> extern int init_test_probes(void);
>> @@ -379,11 +406,6 @@ void unregister_kretprobes(struct kretprobe **rps, int num);
>> void kprobe_flush_task(struct task_struct *tk);
>> void recycle_rp_inst(struct kretprobe_instance *ri, struct hlist_head *head);
>>
>> -int disable_kprobe(struct kprobe *kp);
>> -int enable_kprobe(struct kprobe *kp);
>> -
>> -void dump_kprobe(struct kprobe *kp);
>> -
>> #else /* !CONFIG_KPROBES: */
>>
>> static inline int kprobes_built_in(void)
>> @@ -459,14 +481,6 @@ static inline int enable_kprobe(struct kprobe *kp)
>> return -ENOSYS;
>> }
>> #endif /* CONFIG_KPROBES */
>> -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);
>> -}
>> static inline int disable_jprobe(struct jprobe *jp)
>> {
>> return disable_kprobe(&jp->kp);
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index ceeadfc..e305a81 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
> [...]
>> @@ -1936,8 +1955,44 @@ static int __kprobes pre_handler_kretprobe(struct kprobe *p,
>> return 0;
>> }
>>
>> +void __kprobes recycle_rp_inst(struct kretprobe_instance *ri,
>> + struct hlist_head *head)
>> +{
>> +}
>> +
>> +void __kprobes kretprobe_hash_lock(struct task_struct *tsk,
>> + struct hlist_head **head, unsigned long *flags)
>> +__acquires(hlist_lock)
>> +{
>> +}
>> +
>> +void __kprobes kretprobe_hash_unlock(struct task_struct *tsk,
>> + unsigned long *flags)
>> +__releases(hlist_lock)
>> +{
>> +}
>> +
>
>> +static void __kprobes kretprobe_flush_task(struct task_struct *tk)
>> +{
>> +}
>> +
>> +static void __init init_kretprobes(void)
>> +{
>> +}
>
> These should be macros, as I did for optprobe functions
> with !CONFIG_OPTPROBES.
>
OK, thanks, it sounds reasonable to me.
- For new added static functions: kretprobe_flush_task(), and
init_kretprobes() need be changed to macros
- For extern functions: recycle_rp_inst(), kretprobe_hash_lock(), and
kretprobe_has_unlock(), need use dummy functions.
- For original static function: pre_handler_kretprobe(), need still
use dummy function (for function pointer comparing).
> Other parts looks good to me!;)
>
> Thank you!
>
>
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
next prev parent reply other threads:[~2014-02-04 12:07 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 [this message]
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
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=52F0D7F3.7000901@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).