From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Roel Kluin <12o3l@tiscali.nl>
Cc: linux-kernel@vger.kernel.org,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
prasanna@in.ibm.com, anil.s.keshavamurthy@intel.com,
davem@davemloft.net
Subject: Re: [rfc-patch 07/11] Text Edit Lock - kprobes architecture independent support
Date: Sat, 17 Nov 2007 10:02:36 -0500 [thread overview]
Message-ID: <20071117150236.GA16091@Krystal> (raw)
In-Reply-To: <473EBFBA.7080705@tiscali.nl>
* Roel Kluin (12o3l@tiscali.nl) wrote:
[...]
> > for (i = 0; i < KPROBE_TABLE_SIZE; i++) {
> > head = &kprobe_table[i];
> > + kernel_text_lock();
> > hlist_for_each_entry_rcu(p, node, head, hlist)
> > arch_arm_kprobe(p);
> > + kernel_text_unlock();
> > }
>
> isn't it better to put the kernel_text_lock around the for loop?
>
> >
> > kprobe_enabled = true;
> > @@ -969,10 +974,12 @@ static void __kprobes disable_all_kprobe
> > printk(KERN_INFO "Kprobes globally disabled\n");
> > for (i = 0; i < KPROBE_TABLE_SIZE; i++) {
> > head = &kprobe_table[i];
> > + kernel_text_lock();
> > hlist_for_each_entry_rcu(p, node, head, hlist) {
> > if (!arch_trampoline_kprobe(p))
> > arch_disarm_kprobe(p);
> > }
> > + kernel_text_unlock();
> > }
>
> same question here
>
Yes, you are right, although it does not have to be fast. Here is the
updated patch.
Text Edit Lock - kprobes architecture independent support
Use the mutual exclusion provided by the text edit lock in the kprobes code. It
allows coherent manipulation of the kernel code by other subsystems.
Changelog:
Move the kernel_text_lock/unlock out of the for loops.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: prasanna@in.ibm.com
CC: ananth@in.ibm.com
CC: anil.s.keshavamurthy@intel.com
CC: davem@davemloft.net
CC: Roel Kluin <12o3l@tiscali.nl>
---
kernel/kprobes.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
Index: linux-2.6-lttng/kernel/kprobes.c
===================================================================
--- linux-2.6-lttng.orig/kernel/kprobes.c 2007-11-16 13:40:06.000000000 -0500
+++ linux-2.6-lttng/kernel/kprobes.c 2007-11-17 10:00:23.000000000 -0500
@@ -43,6 +43,7 @@
#include <linux/seq_file.h>
#include <linux/debugfs.h>
#include <linux/kdebug.h>
+#include <linux/memory.h>
#include <asm-generic/sections.h>
#include <asm/cacheflush.h>
@@ -568,9 +569,10 @@ static int __kprobes __register_kprobe(s
goto out;
}
+ kernel_text_lock();
ret = arch_prepare_kprobe(p);
if (ret)
- goto out;
+ goto out_unlock_text;
INIT_HLIST_NODE(&p->hlist);
hlist_add_head_rcu(&p->hlist,
@@ -578,7 +580,8 @@ static int __kprobes __register_kprobe(s
if (kprobe_enabled)
arch_arm_kprobe(p);
-
+out_unlock_text:
+ kernel_text_unlock();
out:
mutex_unlock(&kprobe_mutex);
@@ -621,8 +624,11 @@ valid_p:
* enabled - otherwise, the breakpoint would already have
* been removed. We save on flushing icache.
*/
- if (kprobe_enabled)
+ if (kprobe_enabled) {
+ kernel_text_lock();
arch_disarm_kprobe(p);
+ kernel_text_unlock();
+ }
hlist_del_rcu(&old_p->hlist);
cleanup_p = 1;
} else {
@@ -644,9 +650,7 @@ valid_p:
list_del_rcu(&p->list);
kfree(old_p);
}
- mutex_lock(&kprobe_mutex);
arch_remove_kprobe(p);
- mutex_unlock(&kprobe_mutex);
} else {
mutex_lock(&kprobe_mutex);
if (p->break_handler)
@@ -717,7 +721,6 @@ static int __kprobes pre_handler_kretpro
ri->rp = rp;
ri->task = current;
arch_prepare_kretprobe(ri, regs);
-
/* XXX(hch): why is there no hlist_move_head? */
hlist_del(&ri->uflist);
hlist_add_head(&ri->uflist, &ri->rp->used_instances);
@@ -938,11 +941,13 @@ static void __kprobes enable_all_kprobes
if (kprobe_enabled)
goto already_enabled;
+ kernel_text_lock();
for (i = 0; i < KPROBE_TABLE_SIZE; i++) {
head = &kprobe_table[i];
hlist_for_each_entry_rcu(p, node, head, hlist)
arch_arm_kprobe(p);
}
+ kernel_text_unlock();
kprobe_enabled = true;
printk(KERN_INFO "Kprobes globally enabled\n");
@@ -967,6 +972,7 @@ static void __kprobes disable_all_kprobe
kprobe_enabled = false;
printk(KERN_INFO "Kprobes globally disabled\n");
+ kernel_text_lock();
for (i = 0; i < KPROBE_TABLE_SIZE; i++) {
head = &kprobe_table[i];
hlist_for_each_entry_rcu(p, node, head, hlist) {
@@ -974,6 +980,7 @@ static void __kprobes disable_all_kprobe
arch_disarm_kprobe(p);
}
}
+ kernel_text_unlock();
mutex_unlock(&kprobe_mutex);
/* Allow all currently running kprobes to complete */
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-11-17 15:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-16 19:57 [rfc-patch 00/11] Text Edit Lock for 2.6.24-rc2-git5 Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 01/11] Kprobes - use a mutex to protect the instruction pages list Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 02/11] Kprobes - do not use kprobes mutex in arch code Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 03/11] Kprobes - declare kprobe_mutex static Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 04/11] Add INIT_ARRAY() to kernel.h Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 05/11] Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 06/11] Text Edit Lock - Alternative code for x86 Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 07/11] Text Edit Lock - kprobes architecture independent support Mathieu Desnoyers
2007-11-17 10:17 ` Roel Kluin
2007-11-17 15:02 ` Mathieu Desnoyers [this message]
2007-11-16 19:57 ` [rfc-patch 08/11] Text Edit Lock - kprobes x86_32 Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 09/11] Text Edit Lock - kprobes x86_64 Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 10/11] Text Edit Lock - x86_32 standardize debug rodata Mathieu Desnoyers
2007-11-16 19:57 ` [rfc-patch 11/11] Text Edit Lock - x86_64 " Mathieu Desnoyers
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=20071117150236.GA16091@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=12o3l@tiscali.nl \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=prasanna@in.ibm.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