lkml.org 
[lkml]   [2003]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.5.70-bk1[23]: load_module crashes when aborting module load
Date
In message <200306091014.h59AEnU08591@adam.yggdrasil.com> you write:
> Hi Rusty,
>
> I thought I should report this problem to you now, as I'm
> about to have to explore some code that I'm not too familiar with
> (vfree) as I continue debugging it. Also note I am running a
> modified kernel/module.c, so it is remotely possible that this problem
> is self-inflicted, but I don't think so.
>
> In 2.5.70-bk1[23], I get a kernel bad memory reference
> when trying load a module with an undefined symbol that is not found.
> The bad memory reference occurs in load_module after the call
> to module_free(mod,mod->module_core), the next time that "mod" is
> dereferenced. Here is a commented excerpt from load_module
> in kernel/module.c:
>
> cleanup:
> module_unload_free(mod);
> module_free(mod, mod->module_init);
> free_core:
> module_free(mod, mod->module_core);
> /* The following "if" statement generates a kernel bad memory
> reference. --Adam */
> free_percpu:
> if (mod->percpu)
> percpu_modfree(mod->percpu);
>
> For whatever reason, module->module_core (ee820000) points to
> an address slightly before mod (mod = ee828780, the bad dereference
> is to ee8298a4). On x86, module_free() is vfree(). I suspect that
> somehow vfree() has gotten confused.

Well, mod is inside module->module_core, so that makes sense: check
the section layout, but usually the .text section is first, then mod
will be near the .data section (turn on debugging in layout_sections
to get the details).

> By the way, there also seems to be a bug in the
> 2.5.70-bk12/kernel/module.c changes where mod->percpu is left unitialized
> if a module has no per-cpu data. I've verified that there really is a
> junk non-zero value in mod->percpu in that case. However, fixing that
> bug does not eliminate this problem.

Something is badly wrong: look in include/linux/module.h and you'll
see the initialization of __this_module (which becomes mod). By
leaving the .percpu member uninitialized, it will be initialized to
NULL.

Random guess: did the build system not rebuild your modules properly
when module.h changed?

Puzzled,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.055 / U:1.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site