linux-kernel.vger.kernel.org archive mirror
 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,
	hskinnemoen@gmail.com, David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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 16:17:24 +0900	[thread overview]
Message-ID: <52F09404.3060502@hitachi.com> (raw)
In-Reply-To: <52F077A1.3020701@gmail.com>

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

So, I think you don't need to change kprobes.h.


> +
> +#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.

Other parts looks good to me!;)

Thank you!


-- 
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  7:17 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 [this message]
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
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=52F09404.3060502@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=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).