Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1197209 > unrolled thread

[RFC 0/4] use rcu_read_lock() during module list walk

Started bySebastian Andrzej Siewior <bigeasy@linutronix.de>
First post2015-07-31 19:10 +0200
Last post2015-07-31 19:10 +0200
Articles 2 — 1 participant

Back to article view | Back to linux.kernel


Contents

  [RFC 0/4] use rcu_read_lock() during module list walk Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2015-07-31 19:10 +0200
    [RFC 3/4] kprobes: Add a RCU lock while invoking __module_text_address() Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2015-07-31 19:10 +0200

#1197209 — [RFC 0/4] use rcu_read_lock() during module list walk

FromSebastian Andrzej Siewior <bigeasy@linutronix.de>
Date2015-07-31 19:10 +0200
Subject[RFC 0/4] use rcu_read_lock() during module list walk
Message-ID<pSlYJ-3G7-15@gated-at.bofh.it>
Hi Peter,

this series was made before I noticed that you introduced a RB tree for
lookup but the old way still remains under !CONFIG_MODULES_TREE_LOOKUP.
In the old way the caller had preempt_disable() while invoking
list_for_each_safe_rcu() which is (according to the RCU checklist) not a
substitute for rcu_readlock().
With your CONFIG_MODULES_TREE_LOOKUP I fail to understand what blocks
free_module() until all mod_find() callers have dropped their refrence to
the obtained struct mod. We had synchronize_sched() in RCU case.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1197215 — [RFC 3/4] kprobes: Add a RCU lock while invoking __module_text_address()

FromSebastian Andrzej Siewior <bigeasy@linutronix.de>
Date2015-07-31 19:10 +0200
Subject[RFC 3/4] kprobes: Add a RCU lock while invoking __module_text_address()
Message-ID<pSlYM-3G7-65@gated-at.bofh.it>
In reply to#1197209
delete_module() first sets the module's state to MODULE_STATE_GOING
which means further try_module_get() invocations will fail. However
without a RCU readlock there is nothing that ensures that the pointer
returned by __module_text_address() is still valid in try_module_get().
The preempt_disable() does not protect here against module removal from
another CPU.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 kernel/kprobes.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c90e417bb963..a2d4e5164d7d 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1449,6 +1449,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
 	}
 
 	/* Check if are we probing a module */
+	rcu_read_lock();
 	*probed_mod = __module_text_address((unsigned long) p->addr);
 	if (*probed_mod) {
 		/*
@@ -1457,7 +1458,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
 		 */
 		if (unlikely(!try_module_get(*probed_mod))) {
 			ret = -ENOENT;
-			goto out;
+			goto out_rcu_unlock;
 		}
 
 		/*
@@ -1471,6 +1472,8 @@ static int check_kprobe_address_safe(struct kprobe *p,
 			ret = -ENOENT;
 		}
 	}
+out_rcu_unlock:
+	rcu_read_unlock();
 out:
 	preempt_enable();
 	jump_label_unlock();
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web