| Message ID | 1440072876-8321-2-git-send-email-haokexin@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote: > The jump_label_init() run in a very early stage, even before the > sched_init(). So there is no chance for concurrent access of the > jump label table. It also doesn't hurt to have it. Its better to be consistent and conservative with locking unless there is a pressing need.
On Thu, Aug 20, 2015 at 08:29:03PM +0200, Peter Zijlstra wrote: > On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote: > > The jump_label_init() run in a very early stage, even before the > > sched_init(). So there is no chance for concurrent access of the > > jump label table. > > It also doesn't hurt to have it. Its better to be consistent and > conservative with locking unless there is a pressing need. Yes, it has no real hurt. IMHO it may cause confusion that the function jump_label_init() may run in two different thread context simultaneously. Anyway if you guys don't think so, I can drop this patch. Thanks, Kevin
diff --git a/kernel/jump_label.c b/kernel/jump_label.c index f7dd15d537f9..df1a7fbe7cd5 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -205,7 +205,6 @@ void __init jump_label_init(void) struct static_key *key = NULL; struct jump_entry *iter; - jump_label_lock(); jump_label_sort_entries(iter_start, iter_stop); for (iter = iter_start; iter < iter_stop; iter++) { @@ -229,7 +228,6 @@ void __init jump_label_init(void) #endif } static_key_initialized = true; - jump_label_unlock(); } #ifdef CONFIG_MODULES
The jump_label_init() run in a very early stage, even before the sched_init(). So there is no chance for concurrent access of the jump label table. Signed-off-by: Kevin Hao <haokexin@gmail.com> --- kernel/jump_label.c | 2 -- 1 file changed, 2 deletions(-)