From: Masami Hiramatsu <mhiramat@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Ingo Molnar <mingo@elte.hu>, Jim Keniston <jkenisto@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
systemtap-ml <systemtap@sources.redhat.com>
Subject: Re: [RFC][PATCH -tip 8/9] kprobes: support respawn probes for module probing
Date: Thu, 19 Mar 2009 23:52:52 -0400 [thread overview]
Message-ID: <49C31314.40508@redhat.com> (raw)
In-Reply-To: <20090320011114.GD6895@nowhere>
Frederic Weisbecker wrote:
> On Thu, Mar 19, 2009 at 05:10:44PM -0400, Masami Hiramatsu wrote:
>> Add module_*probe API's to respawn probes on kernel modules.
>> kprobes which have been registered through register_module_*probe are
>> activated when the target module is loaded, and deactivated when unloading.
>> register_module_*probe require an activate_handler which is called right
>> before activating the probe, and if it returns !0, kprobes will be activated.
>>
>> Thus, users can check whether the target module is true target or not
>> (e.g. checking build-id) in activate_handler.
>>
>> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> ---
>> include/linux/kprobes.h | 39 ++++++++
>> kernel/kprobes.c | 250 +++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 289 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>> index 2ec6cc1..9d47d08 100644
>> --- a/include/linux/kprobes.h
>> +++ b/include/linux/kprobes.h
>> @@ -37,6 +37,7 @@
>> #include <linux/spinlock.h>
>> #include <linux/rcupdate.h>
>> #include <linux/mutex.h>
>> +#include <linux/module.h>
>>
>> #ifdef CONFIG_KPROBES
>> #include <asm/kprobes.h>
>> @@ -69,6 +70,7 @@ typedef int (*kprobe_fault_handler_t) (struct kprobe *, struct pt_regs *,
>> int trapnr);
>> typedef int (*kretprobe_handler_t) (struct kretprobe_instance *,
>> struct pt_regs *);
>> +typedef int (*probe_activate_handler_t)(void *, struct module *);
>
>
> I guess it could also be useful to call the handler when the module
> is unloaded. Be using another parameter with a LOAD/UNLOAD enum value.
Hmm, when unloading module, kprobes becomes "gone". So I think we don't
need to check whether it can be deactivated or not when unloading.
>> struct kprobe {
>> struct hlist_node hlist;
>> @@ -279,6 +281,16 @@ 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 register_module_kprobe(struct kprobe *kp,
>> + probe_activate_handler_t handler, void *data);
>> +int register_module_kretprobe(struct kretprobe *rp,
>> + probe_activate_handler_t handler, void *data);
>> +int register_module_jprobe(struct jprobe *jp,
>> + probe_activate_handler_t handler, void *data);
>> +void unregister_module_kprobe(struct kprobe *kp);
>> +void unregister_module_kretprobe(struct kretprobe *rp);
>> +void unregister_module_jprobe(struct jprobe *jp);
>> +
>> #else /* !CONFIG_KPROBES: */
>>
>> static inline int kprobes_built_in(void)
>> @@ -345,5 +357,32 @@ static inline void unregister_kretprobes(struct kretprobe **rps, int num)
>> static inline void kprobe_flush_task(struct task_struct *tk)
>> {
>> }
>> +static inline int register_module_kprobe(struct kprobe *kp,
>> + probe_activate_handler_t handler,
>> + void *data)
>> +{
>> + return -ENOSYS;
>> +}
>> +static inline int register_module_kretprobe(struct kretprobe *rp,
>> + probe_activate_handler_t handler,
>> + void *data)
>> +{
>> + return -ENOSYS;
>> +}
>> +static inline int register_module_jprobe(struct jprobe *jp,
>> + probe_activate_handler_t handler,
>> + void *data)
>> +{
>> + return -ENOSYS;
>> +}
>> +void unregister_module_kprobe(struct kprobe *kp)
>> +{
>> +}
>> +void unregister_module_kretprobe(struct kretprobe *rp)
>> +{
>> +}
>> +void unregister_module_jprobe(struct jprobe *jp)
>> +{
>> +}
>
>
> Shouldn't the unregister_* be inlined too?
> I think they all could be static inlined too in case of !CONFIG_MODULE
Ah, right... it was my mistake.
>> #endif /* CONFIG_KPROBES */
>> #endif /* _LINUX_KPROBES_H */
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index 5016bfb..f16a54e 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
>> @@ -1416,6 +1416,256 @@ static int __kprobes debugfs_kprobe_init(void)
>> late_initcall(debugfs_kprobe_init);
>> #endif /* CONFIG_DEBUG_FS */
>>
>> +/* Kprobes module respawn support */
>> +enum probe_type {
>> + PROBE_TYPE_KPROBE,
>> + PROBE_TYPE_KRETPROBE,
>> + PROBE_TYPE_JPROBE,
>> +};
>> +
>> +struct module_probe_client {
>> + struct list_head list;
>> + const char *module; /* including symbol name */
>> + int active;
>> + void *data;
>> + probe_activate_handler_t handler;
>> + enum probe_type type;
>> + union {
>> + struct kprobe *kp;
>> + struct kretprobe *rp;
>> + struct jprobe *jp;
>> + };
>> +};
>
>
> #ifdef CONFIG_MODULE ?
>
> Frederic.
Yes.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2009-03-20 3:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 21:10 [RFC][PATCH -tip 8/9] kprobes: support respawn probes for module probing Masami Hiramatsu
2009-03-20 1:11 ` Frederic Weisbecker
2009-03-20 3:52 ` Masami Hiramatsu [this message]
2009-03-20 1:19 ` Frederic Weisbecker
2009-03-20 3:48 ` Masami Hiramatsu
2009-03-21 0:08 ` Frederic Weisbecker
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=49C31314.40508@redhat.com \
--to=mhiramat@redhat.com \
--cc=ananth@in.ibm.com \
--cc=fweisbec@gmail.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=systemtap@sources.redhat.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.