Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 11:12:22AM -0700, Stone, Joshua I wrote: > The ability to disable/reenable kprobes would be an interesting > enhancement. However, unregister_disabled_kprobes() shouldn't have a > global effect, because there might be a concurrent kprobes user that > disabled a probe with the intention of reenabling it later. enabling/disabling probes sounds like a wonderful additional feature. I don't think we should expose it as a kernel interface, but rather through debugfs so I can temporarily disable and then reenable probes from the shell easily. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 02:22:48PM -0400, Frank Ch. Eigler wrote: > Really? What possible problems can occur? The worst that occurs to > me is that if someone forgets to call the commit function, the kprobes > will still be disabled, but memory won't be recycled for a while. Exactly. It's a very unintuitive interface, exposing implementation details to the user. The array variant otoh is obvious to the user: gice me an array of probes to register/unregister and do it. > Would it be possible to allay even that concern with an automated > deferred/periodic commit? That's even worse from the user perspective interface. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 02:22:48PM -0400, Frank Ch. Eigler wrote: Really? What possible problems can occur? The worst that occurs to me is that if someone forgets to call the commit function, the kprobes will still be disabled, but memory won't be recycled for a while. Exactly. It's a very unintuitive interface, exposing implementation details to the user. The array variant otoh is obvious to the user: gice me an array of probes to register/unregister and do it. Would it be possible to allay even that concern with an automated deferred/periodic commit? That's even worse from the user perspective interface. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 11:12:22AM -0700, Stone, Joshua I wrote: The ability to disable/reenable kprobes would be an interesting enhancement. However, unregister_disabled_kprobes() shouldn't have a global effect, because there might be a concurrent kprobes user that disabled a probe with the intention of reenabling it later. enabling/disabling probes sounds like a wonderful additional feature. I don't think we should expose it as a kernel interface, but rather through debugfs so I can temporarily disable and then reenable probes from the shell easily. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi Anil, Keshavamurthy, Anil S wrote: > On Mon, Mar 26, 2007 at 12:17:49PM +0900, Masami Hiramatsu wrote: >> Hi Christoph and Anil, >> >> Thank you for your comments. >> >> Christoph Hellwig wrote: >>> Speeding up the unregistration is a very good idea, but this interface >>> is rather horrible. It's almost a receipe for users to get it wrong. >> Keshavamurthy, Anil S wrote: >>> I agree with Christop that the interface is horrible and error prone. >> OK, I agree. I had chosen a confusable name. > Keep in mind that the the sequence of unregistering a > probe should be same irrespecitve of whether user wants > to unregister a single probe or user want to > unregister more that one probe, i.e. you can not say > use this call (unregister_kprobe() ) for unregistering > a probe which is b.t.w slow and use this set of calls if you > have more than one kprobes to unregister for faster unregistration. Would you mean that we should integrate unregistration interface? Or, would you mean that you prefer "disable_kprobe()" since that name provides another meaning? Thanks, -- Masami HIRAMATSU Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi Anil, Keshavamurthy, Anil S wrote: On Mon, Mar 26, 2007 at 12:17:49PM +0900, Masami Hiramatsu wrote: Hi Christoph and Anil, Thank you for your comments. Christoph Hellwig wrote: Speeding up the unregistration is a very good idea, but this interface is rather horrible. It's almost a receipe for users to get it wrong. Keshavamurthy, Anil S wrote: I agree with Christop that the interface is horrible and error prone. OK, I agree. I had chosen a confusable name. Keep in mind that the the sequence of unregistering a probe should be same irrespecitve of whether user wants to unregister a single probe or user want to unregister more that one probe, i.e. you can not say use this call (unregister_kprobe() ) for unregistering a probe which is b.t.w slow and use this set of calls if you have more than one kprobes to unregister for faster unregistration. Would you mean that we should integrate unregistration interface? Or, would you mean that you prefer disable_kprobe() since that name provides another meaning? Thanks, -- Masami HIRAMATSU Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi Christoph and Anil,
Thank you for your comments.
Christoph Hellwig wrote:
> Speeding up the unregistration is a very good idea, but this interface
> is rather horrible. It's almost a receipe for users to get it wrong.
Keshavamurthy, Anil S wrote:
> I agree with Christop that the interface is horrible and error prone.
OK, I agree. I had chosen a confusable name.
> However, I see the use case where people want to disable the probes quickly
> and
> would like to reenable them again. Looking closely at your patch,
> I think this can be acheived.
Thank you.
> Here is my suggestion.
>
>> Here is an example code.
>> --
>> struct kprobes *p;
>> for_each_probe(p) {
>> unregister_kprobe_fast(p);
> ^^
> Change this to disable_kprobe(p), which is essentially the same as
> what you have implemented. And also provide an opposite function
> to reenable_kprobe(p) which enables the disabled probe again.
I'd like to change that to prepare_to_unregister_kprobe(p) instead of
disable_kprobe(p).
I think Josh and other people want interfaces to disable/reenable all
probes at once when the sysrq is pressed.
So, IMHO, these interfaces should use a global (and per-cpu?) flag which
controls whether kprobes calls user-defined handler or not, instead of
self-modifying.
For example,
if (p && p->pre_handler && kprobe_enable) {
^
...
}
But, I think this would be another story.
I'd like to discuss this topic in other mails.
>> }
>> commit_kprobes();
> ^^
> Change this to unregister_disabled_kprobes(), which essentially
> unregisters all the disabled probes.
And also, I'd like to change it to unregister_prepared_kprobes().
What would you think about this idea?
Thanks,
>
> Thanks,
> Anil Keshavamurthy
>
--
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi - "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> writes: > [...] > > Really? What possible problems can occur? The worst that occurs > > to me is that if someone forgets to call the commit function, the > > kprobes will still be disabled, but memory won't be recycled for a > > while. [...] > > Yes, Have you looked at the code? A little, but we were talking more about the interface than the implementation. > If someone forgets to call the commit function, the kprobe will be > disabled and yes the memory won't be recycled but the worst problem > is that if the probe is on a module function then that module can't > be unloaded at all [...] I believe there is already a kprobes patch in the queue for enumerating active probes in some /proc file. Should a module be locked into memory for such a reason, finding the culprit should not be difficult. > Hence, my suggestion would be to call them as disable_kprobe() > (instead of unregister_kprobes_fast() which is confusing and error > prone) and also to provide an opposite function to reenable_kprobe() > and finally provide unregister_disabled_kprobes() which is > essentially the same as commit_kprobes(). One problem with this idea is that if the unregister_fast()=disable() is to become reversible, then the renamed commit_kprobes() will no longer be indempotent. There can no longer be a single system-wide deferred-kprobe-cleanup list, since individual kprobes clients might want to reinstate their probes in the future. > > Would it be possible to allay even that concern with an automated > > deferred/periodic commit? > > > I would recomand that users call unregister_disabled_kprobes() explictly. But this would solve both problems (memory leaks and outstanding reference counts on modules). In this variant, unregister_kprobes_fast could replace unregister_kprobes outright, and the (builtin deferred) commit function would need not be exported. - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi - Keshavamurthy, Anil S [EMAIL PROTECTED] writes: [...] Really? What possible problems can occur? The worst that occurs to me is that if someone forgets to call the commit function, the kprobes will still be disabled, but memory won't be recycled for a while. [...] Yes, Have you looked at the code? A little, but we were talking more about the interface than the implementation. If someone forgets to call the commit function, the kprobe will be disabled and yes the memory won't be recycled but the worst problem is that if the probe is on a module function then that module can't be unloaded at all [...] I believe there is already a kprobes patch in the queue for enumerating active probes in some /proc file. Should a module be locked into memory for such a reason, finding the culprit should not be difficult. Hence, my suggestion would be to call them as disable_kprobe() (instead of unregister_kprobes_fast() which is confusing and error prone) and also to provide an opposite function to reenable_kprobe() and finally provide unregister_disabled_kprobes() which is essentially the same as commit_kprobes(). One problem with this idea is that if the unregister_fast()=disable() is to become reversible, then the renamed commit_kprobes() will no longer be indempotent. There can no longer be a single system-wide deferred-kprobe-cleanup list, since individual kprobes clients might want to reinstate their probes in the future. Would it be possible to allay even that concern with an automated deferred/periodic commit? I would recomand that users call unregister_disabled_kprobes() explictly. But this would solve both problems (memory leaks and outstanding reference counts on modules). In this variant, unregister_kprobes_fast could replace unregister_kprobes outright, and the (builtin deferred) commit function would need not be exported. - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi Christoph and Anil,
Thank you for your comments.
Christoph Hellwig wrote:
Speeding up the unregistration is a very good idea, but this interface
is rather horrible. It's almost a receipe for users to get it wrong.
Keshavamurthy, Anil S wrote:
I agree with Christop that the interface is horrible and error prone.
OK, I agree. I had chosen a confusable name.
However, I see the use case where people want to disable the probes quickly
and
would like to reenable them again. Looking closely at your patch,
I think this can be acheived.
Thank you.
Here is my suggestion.
Here is an example code.
--
struct kprobes *p;
for_each_probe(p) {
unregister_kprobe_fast(p);
^^
Change this to disable_kprobe(p), which is essentially the same as
what you have implemented. And also provide an opposite function
to reenable_kprobe(p) which enables the disabled probe again.
I'd like to change that to prepare_to_unregister_kprobe(p) instead of
disable_kprobe(p).
I think Josh and other people want interfaces to disable/reenable all
probes at once when the sysrq is pressed.
So, IMHO, these interfaces should use a global (and per-cpu?) flag which
controls whether kprobes calls user-defined handler or not, instead of
self-modifying.
For example,
if (p p-pre_handler kprobe_enable) {
^
...
}
But, I think this would be another story.
I'd like to discuss this topic in other mails.
}
commit_kprobes();
^^
Change this to unregister_disabled_kprobes(), which essentially
unregisters all the disabled probes.
And also, I'd like to change it to unregister_prepared_kprobes().
What would you think about this idea?
Thanks,
Thanks,
Anil Keshavamurthy
--
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi - Keshavamurthy, Anil S wrote: > I agree with Christoph that the interface is horrible and error prone. Really? What possible problems can occur? The worst that occurs to me is that if someone forgets to call the commit function, the kprobes will still be disabled, but memory won't be recycled for a while. Is this really so bad, considering that a kprobe_unregister is to imply a commit? Maybe if kprobe_register can also implied a commit, we can bound the conceivable memory leak. Would it be possible to allay even that concern with an automated deferred/periodic commit? - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][Patch 1/4] kprobe fast unregistration
Keshavamurthy, Anil S wrote:
> I agree with Christop that the interface is horrible and error prone.
> However, I see the use case where people want to disable the probes
> quickly and would like to reenable them again. Looking closely at
> your patch,
> I think this can be acheived.
> Here is my suggestion.
>
>> Here is an example code.
>> --
>> struct kprobes *p;
>> for_each_probe(p) {
>> unregister_kprobe_fast(p);
> ^^
> Change this to disable_kprobe(p), which is essentially the same as
> what you have implemented. And also provide an opposite function
> to reenable_kprobe(p) which enables the disabled probe again.
>> }
>> commit_kprobes();
> ^^
> Change this to unregister_disabled_kprobes(), which essentially
> unregisters all the disabled probes.
The ability to disable/reenable kprobes would be an interesting
enhancement. However, unregister_disabled_kprobes() shouldn't have a
global effect, because there might be a concurrent kprobes user that
disabled a probe with the intention of reenabling it later.
Josh Stone
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 11:43:48PM +0900, Masami Hiramatsu wrote: > I'd like to suggest introducing following two interfaces for this issue. > The first interface is unregister_*probe_fast(). This removes > breakpoint instruction from kernel code and adds specified probe > to the unregistering list. > The second interface is commit_kprobes(). This waits the rcu > synchronization and clean up each probe on the unregistering list. > This patch also adds a list_head member to the kprobe data structure > for linking to the unregistering list. > > If using these interfaces, the probe handlers of unregistering probes > might be called after unregister_*probe_fast() is called. So, you MUST > call commit_kprobes() after calling unregisnter_*probe_fast() for all > probes. Speeding up the unregistration is a very good idea, but this interface is rather horrible. It's almost a receipe for users to get it wrong. Instead just changes the register and unregister functions to take a NULL-terminated array of probes that get registered and unregisters at the same time (and renames them from *probe* to *probes*, please) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][Patch 1/4] kprobe fast unregistration
Hi Ananth,
Here is a series of patches which introduce two kinds of interfaces
for speeding up unregistering process of kprobes.
Currently, the unregister_*probe() function takes a long time to
unregister specified probe because it waits the rcu synchronization
after each unregistration. So we need to introduce new method for
unregistering a lot of probes at once.
I'd like to suggest introducing following two interfaces for this issue.
The first interface is unregister_*probe_fast(). This removes
breakpoint instruction from kernel code and adds specified probe
to the unregistering list.
The second interface is commit_kprobes(). This waits the rcu
synchronization and clean up each probe on the unregistering list.
This patch also adds a list_head member to the kprobe data structure
for linking to the unregistering list.
If using these interfaces, the probe handlers of unregistering probes
might be called after unregister_*probe_fast() is called. So, you MUST
call commit_kprobes() after calling unregisnter_*probe_fast() for all
probes.
It is safe even if several threads unregister probes simultaneously,
because the unregistration process is protected by kprobe_lock mutex.
If one thread calls commit_kprobes(), it will cleanup not only its probes
but also the other thread's probes. And it is transparently done.
If there is no unregistering probes, commit_kprobes() do nothing.
Here is an example code.
--
struct kprobes *p;
for_each_probe(p) {
unregister_kprobe_fast(p);
}
commit_kprobes();
--
Best regards,
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
This patch introduces unregister_kprobe_fast() and commit_kprobes().
arch/i386/kernel/kprobes.c|2
arch/ia64/kernel/kprobes.c|2
arch/powerpc/kernel/kprobes.c |2
arch/s390/kernel/kprobes.c|2
arch/x86_64/kernel/kprobes.c |2
include/linux/kprobes.h | 11 +++
kernel/kprobes.c | 138 +++---
7 files changed, 115 insertions(+), 44 deletions(-)
Index: linux-2.6.21-rc4-mm1/include/linux/kprobes.h
===
--- linux-2.6.21-rc4-mm1.orig/include/linux/kprobes.h
+++ linux-2.6.21-rc4-mm1/include/linux/kprobes.h
@@ -68,6 +68,9 @@ struct kprobe {
/* list of kprobes for multi-handler support */
struct list_head list;
+ /* list of kprobes for fast unregistering support */
+ struct list_head commit_list;
+
/* Indicates that the corresponding module has been ref counted */
unsigned int mod_refcounted;
@@ -190,6 +193,8 @@ static inline struct kprobe_ctlblk *get_
int register_kprobe(struct kprobe *p);
void unregister_kprobe(struct kprobe *p);
+void unregister_kprobe_fast(struct kprobe *p);
+void commit_kprobes(void);
int setjmp_pre_handler(struct kprobe *, struct pt_regs *);
int longjmp_break_handler(struct kprobe *, struct pt_regs *);
int register_jprobe(struct jprobe *p);
@@ -220,6 +225,9 @@ static inline int register_kprobe(struct
static inline void unregister_kprobe(struct kprobe *p)
{
}
+static inline void unregister_kprobe_fast(struct kprobe *p)
+{
+}
static inline int register_jprobe(struct jprobe *p)
{
return -ENOSYS;
@@ -240,5 +248,8 @@ static inline void unregister_kretprobe(
static inline void kprobe_flush_task(struct task_struct *tk)
{
}
+static inline void commit_kprobes(void)
+{
+}
#endif /* CONFIG_KPROBES */
#endif /* _LINUX_KPROBES_H */
Index: linux-2.6.21-rc4-mm1/kernel/kprobes.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/kprobes.c
+++ linux-2.6.21-rc4-mm1/kernel/kprobes.c
@@ -62,6 +62,8 @@
static struct hlist_head kprobe_table[KPROBE_TABLE_SIZE];
static struct hlist_head kretprobe_inst_table[KPROBE_TABLE_SIZE];
static atomic_t kprobe_count;
+static LIST_HEAD(clean_probe_list);
+static LIST_HEAD(dirty_probe_list);
DEFINE_MUTEX(kprobe_mutex);/* Protects kprobe_table */
DEFINE_SPINLOCK(kretprobe_lock); /* Protects kretprobe_inst_table */
@@ -584,6 +586,8 @@ static int __kprobes __register_kprobe(s
}
p->nmissed = 0;
+ /* Initialize multiprobe list for __unregister_kprobe_bottom() */
+ INIT_LIST_HEAD(>list);
mutex_lock(_mutex);
old_p = get_kprobe(p->addr);
if (old_p) {
@@ -596,6 +600,7 @@ static int __kprobes __register_kprobe(s
if ((ret = arch_prepare_kprobe(p)) != 0)
goto out;
+ INIT_LIST_HEAD(>commit_list);
INIT_HLIST_NODE(>hlist);
hlist_add_head_rcu(>hlist,
_table[hash_ptr(p->addr, KPROBE_HASH_BITS)]);
@@ -620,80 +625,143 @@ int __kprobes register_kprobe(struct kpr
(unsigned long)__builtin_return_address(0));
}
-void __kprobes unregister_kprobe(struct kprobe *p)
+/*
+ * Unregister a kprobe without a scheduler synchronization.
+ * You have to invoke
[RFC][Patch 1/4] kprobe fast unregistration
Hi Ananth,
Here is a series of patches which introduce two kinds of interfaces
for speeding up unregistering process of kprobes.
Currently, the unregister_*probe() function takes a long time to
unregister specified probe because it waits the rcu synchronization
after each unregistration. So we need to introduce new method for
unregistering a lot of probes at once.
I'd like to suggest introducing following two interfaces for this issue.
The first interface is unregister_*probe_fast(). This removes
breakpoint instruction from kernel code and adds specified probe
to the unregistering list.
The second interface is commit_kprobes(). This waits the rcu
synchronization and clean up each probe on the unregistering list.
This patch also adds a list_head member to the kprobe data structure
for linking to the unregistering list.
If using these interfaces, the probe handlers of unregistering probes
might be called after unregister_*probe_fast() is called. So, you MUST
call commit_kprobes() after calling unregisnter_*probe_fast() for all
probes.
It is safe even if several threads unregister probes simultaneously,
because the unregistration process is protected by kprobe_lock mutex.
If one thread calls commit_kprobes(), it will cleanup not only its probes
but also the other thread's probes. And it is transparently done.
If there is no unregistering probes, commit_kprobes() do nothing.
Here is an example code.
--
struct kprobes *p;
for_each_probe(p) {
unregister_kprobe_fast(p);
}
commit_kprobes();
--
Best regards,
Signed-off-by: Masami Hiramatsu [EMAIL PROTECTED]
---
This patch introduces unregister_kprobe_fast() and commit_kprobes().
arch/i386/kernel/kprobes.c|2
arch/ia64/kernel/kprobes.c|2
arch/powerpc/kernel/kprobes.c |2
arch/s390/kernel/kprobes.c|2
arch/x86_64/kernel/kprobes.c |2
include/linux/kprobes.h | 11 +++
kernel/kprobes.c | 138 +++---
7 files changed, 115 insertions(+), 44 deletions(-)
Index: linux-2.6.21-rc4-mm1/include/linux/kprobes.h
===
--- linux-2.6.21-rc4-mm1.orig/include/linux/kprobes.h
+++ linux-2.6.21-rc4-mm1/include/linux/kprobes.h
@@ -68,6 +68,9 @@ struct kprobe {
/* list of kprobes for multi-handler support */
struct list_head list;
+ /* list of kprobes for fast unregistering support */
+ struct list_head commit_list;
+
/* Indicates that the corresponding module has been ref counted */
unsigned int mod_refcounted;
@@ -190,6 +193,8 @@ static inline struct kprobe_ctlblk *get_
int register_kprobe(struct kprobe *p);
void unregister_kprobe(struct kprobe *p);
+void unregister_kprobe_fast(struct kprobe *p);
+void commit_kprobes(void);
int setjmp_pre_handler(struct kprobe *, struct pt_regs *);
int longjmp_break_handler(struct kprobe *, struct pt_regs *);
int register_jprobe(struct jprobe *p);
@@ -220,6 +225,9 @@ static inline int register_kprobe(struct
static inline void unregister_kprobe(struct kprobe *p)
{
}
+static inline void unregister_kprobe_fast(struct kprobe *p)
+{
+}
static inline int register_jprobe(struct jprobe *p)
{
return -ENOSYS;
@@ -240,5 +248,8 @@ static inline void unregister_kretprobe(
static inline void kprobe_flush_task(struct task_struct *tk)
{
}
+static inline void commit_kprobes(void)
+{
+}
#endif /* CONFIG_KPROBES */
#endif /* _LINUX_KPROBES_H */
Index: linux-2.6.21-rc4-mm1/kernel/kprobes.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/kprobes.c
+++ linux-2.6.21-rc4-mm1/kernel/kprobes.c
@@ -62,6 +62,8 @@
static struct hlist_head kprobe_table[KPROBE_TABLE_SIZE];
static struct hlist_head kretprobe_inst_table[KPROBE_TABLE_SIZE];
static atomic_t kprobe_count;
+static LIST_HEAD(clean_probe_list);
+static LIST_HEAD(dirty_probe_list);
DEFINE_MUTEX(kprobe_mutex);/* Protects kprobe_table */
DEFINE_SPINLOCK(kretprobe_lock); /* Protects kretprobe_inst_table */
@@ -584,6 +586,8 @@ static int __kprobes __register_kprobe(s
}
p-nmissed = 0;
+ /* Initialize multiprobe list for __unregister_kprobe_bottom() */
+ INIT_LIST_HEAD(p-list);
mutex_lock(kprobe_mutex);
old_p = get_kprobe(p-addr);
if (old_p) {
@@ -596,6 +600,7 @@ static int __kprobes __register_kprobe(s
if ((ret = arch_prepare_kprobe(p)) != 0)
goto out;
+ INIT_LIST_HEAD(p-commit_list);
INIT_HLIST_NODE(p-hlist);
hlist_add_head_rcu(p-hlist,
kprobe_table[hash_ptr(p-addr, KPROBE_HASH_BITS)]);
@@ -620,80 +625,143 @@ int __kprobes register_kprobe(struct kpr
(unsigned long)__builtin_return_address(0));
}
-void __kprobes unregister_kprobe(struct kprobe *p)
+/*
+ * Unregister a kprobe without a scheduler synchronization.
+ * You have
Re: [RFC][Patch 1/4] kprobe fast unregistration
On Fri, Mar 23, 2007 at 11:43:48PM +0900, Masami Hiramatsu wrote: I'd like to suggest introducing following two interfaces for this issue. The first interface is unregister_*probe_fast(). This removes breakpoint instruction from kernel code and adds specified probe to the unregistering list. The second interface is commit_kprobes(). This waits the rcu synchronization and clean up each probe on the unregistering list. This patch also adds a list_head member to the kprobe data structure for linking to the unregistering list. If using these interfaces, the probe handlers of unregistering probes might be called after unregister_*probe_fast() is called. So, you MUST call commit_kprobes() after calling unregisnter_*probe_fast() for all probes. Speeding up the unregistration is a very good idea, but this interface is rather horrible. It's almost a receipe for users to get it wrong. Instead just changes the register and unregister functions to take a NULL-terminated array of probes that get registered and unregisters at the same time (and renames them from *probe* to *probes*, please) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][Patch 1/4] kprobe fast unregistration
Keshavamurthy, Anil S wrote:
I agree with Christop that the interface is horrible and error prone.
However, I see the use case where people want to disable the probes
quickly and would like to reenable them again. Looking closely at
your patch,
I think this can be acheived.
Here is my suggestion.
Here is an example code.
--
struct kprobes *p;
for_each_probe(p) {
unregister_kprobe_fast(p);
^^
Change this to disable_kprobe(p), which is essentially the same as
what you have implemented. And also provide an opposite function
to reenable_kprobe(p) which enables the disabled probe again.
}
commit_kprobes();
^^
Change this to unregister_disabled_kprobes(), which essentially
unregisters all the disabled probes.
The ability to disable/reenable kprobes would be an interesting
enhancement. However, unregister_disabled_kprobes() shouldn't have a
global effect, because there might be a concurrent kprobes user that
disabled a probe with the intention of reenabling it later.
Josh Stone
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi - Keshavamurthy, Anil S wrote: I agree with Christoph that the interface is horrible and error prone. Really? What possible problems can occur? The worst that occurs to me is that if someone forgets to call the commit function, the kprobes will still be disabled, but memory won't be recycled for a while. Is this really so bad, considering that a kprobe_unregister is to imply a commit? Maybe if kprobe_register can also implied a commit, we can bound the conceivable memory leak. Would it be possible to allay even that concern with an automated deferred/periodic commit? - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
