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

Groups > linux.kernel > #1178735 > unrolled thread

Re: lock-up with module: Optimize __module_address() using a latched RB-tree

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: lock-up with module: Optimize __module_address() using a  latched RB-tree Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2015-07-07 18:40 +0200
    Re: lock-up with module: Optimize __module_address() using a latched  RB-tree Peter Zijlstra <peterz@infradead.org> - 2015-07-08 14:40 +0200
      [PATCH] module: Fix load_module() error path Peter Zijlstra <peterz@infradead.org> - 2015-07-08 14:50 +0200

#1178735 — Re: lock-up with module: Optimize __module_address() using a latched RB-tree

[Multipart message — attachments visible in raw view] — view raw

----- On Jul 7, 2015, at 3:29 AM, Peter Zijlstra peterz@infradead.org wrote:

> On Tue, Jul 07, 2015 at 02:59:06PM +0930, Arthur Marsh wrote:
>> I had a single, non-reproducible case of the same lock-up happening on my
>> other machine running the Linus git head kernel in 64-bit mode.
> 
> Hmm, disturbing.. I've had my machines run this stuff for weeks and not
> had anything like this :/
> 
> Do you have a serial cable between those machines? serial console output
> will allow capturing more complete traces than these pictures can and
> might also aid in capturing some extra debug info.
> 
> In any case, I'll go try and build some debug code.

Arthur: can you double-check if you load any module with --force ?
This could cause a module header layout mismatch, which can be an
issue with the changes done by the identified commit: the module
header layout changes there.

Also, I'm attaching a small patch which serializes both updates and
reads of the module rbree. Can you try it out ? If the problem
still shows with the spinlocks in place, that would mean the issue
is *not* a race between latched rbtree updates and traversals.

Thanks!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[toc] | [next] | [standalone]

#1179743 — Re: lock-up with module: Optimize __module_address() using a latched RB-tree

On Wed, Jul 08, 2015 at 09:13:15PM +0930, Arthur Marsh wrote:
> I rebuilt again with CONFIG_MODULE_UNLOAD enabled and Peter's patch above
> and the resulting kernel also booted fine.
> 
> Thanks for everyone's help!

Awesome, lemme go write up a proper patch to make Rusty happy too ;-)
--
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] | [next] | [standalone]

#1179745 — [PATCH] module: Fix load_module() error path

On Wed, Jul 08, 2015 at 02:32:44PM +0200, Peter Zijlstra wrote:

> Awesome, lemme go write up a proper patch to make Rusty happy too ;-)

---
Subject: module: Fix load_module() error path
From: Peter Zijlstra <peterz@infradead.org>
Date: Wed Jul 8 14:35:58 CEST 2015

The load_module() error path frees a module but forgot to take it out
of the mod_tree, leaving a dangling entry in the tree, causing havoc.

Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: Arthur Marsh <arthur.marsh@internode.on.net>
Tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
Fixes: 93c2e105f6bc ("module: Optimize __module_address() using a latched RB-tree")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/module.c |    1 +
 1 file changed, 1 insertion(+)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3557,6 +3557,7 @@ static int load_module(struct load_info
 	mutex_lock(&module_mutex);
 	/* Unlink carefully: kallsyms could be walking list. */
 	list_del_rcu(&mod->list);
+	mod_tree_remove(mod);
 	wake_up_all(&module_wq);
 	/* Wait for RCU-sched synchronizing before releasing mod->list. */
 	synchronize_sched();
--
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