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

[Rusty Russell <rusty@rustcorp.com.au>]

Peter Zijlstra <peterz@infradead.org> writes:
> On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
>> On Wed, Jul 08, 2015 at 05:45:45AM +0930, Arthur Marsh wrote:
>> > I'm not aware of any modules being loaded with --force .
>> > 
>> > I've applied the patch, thanks!
>> > 
>> > The resultant kernel locked up as follows:
>> > 
>> > http://www.users.on.net/~arthur.marsh/20150708469.jpg
>> 
>> This has "Not tainted" which would indeed rule out forced loading. So
>> much for that idea :/
>> 
>> > http://www.users.on.net/~arthur.marsh/20150708470.jpg
>> 
>> And that one has a bunch of NMI prints, curious those. But given Mathieu
>> made them return NULL, that completely rules out the most interesting
>> races.
>
> Could you try the below? It appears there was a spot freeing modules
> that forgot to take them out of the tree.

Ouch!  Good catch.

I'm testing that here.... Yep, "modprobe lp reset=7" (which fails to
parse) three times and then oops in __mod_tree_insert.

If you want to wrap that with a SOB and Reported-by/Tested-by if my
compatriot acks...

Thanks!
Rusty.

> ---
>  kernel/module.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 3e0e19763d24..4d2b82e610e2 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3557,6 +3557,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
>  	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();