On Mon, May 05, 2014 at 07:41:33PM +0930, Rusty Russell wrote:
> Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> writes:
> > On Sun, May 4, 2014 at 10:45 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> >> Note that in the case where two modules could satisfy a dependencies,
> >> it may not be a real loop?
> >
> > What do you mean here? How could that be the case for *depmod*?
>
> Sorry, it's a theoretical case; no one does anything this crazy:
>
> A provides symbol S1.
> B provides symbol S1, needs S2.
> C needs S1, provides S2.
> D provides S2.
This never worked. While calculating the dependencies one module will simply
override the previous module providing the symbol... and this will depend on
the path walking order.
However the kernel's modpost already warned about 2 modules providing the same
symbol:
WARNING: /home/lucas/p/kmod/testsuite/module-playground/moduleC: 'printB' exported twice. Previous export was in /home/lucas/p/kmod/testsuite/module-playground/moduleB.ko
And if we try to load it anyway in the kernel, it fails as it should:
[ 618.643592] moduleC: exports duplicate symbol printB (owned by moduleB)
In the case of duplicate symbols, we could make depmod fail as well, just like if there are loops.
For my tests I used the diff below.
----8<---------------
diff --git a/testsuite/module-playground/moduleC.c b/testsuite/module-playground/moduleC.c
index b74cb07..bf5b5aa 100644
--- a/testsuite/module-playground/moduleC.c
+++ b/testsuite/module-playground/moduleC.c
@@ -8,17 +8,16 @@
static int __init test_module_init(void)
{
- printC();
printB();
return 0;
}
module_init(test_module_init);
-void printC(void)
+void printB(void)
{
- pr_warn("Hello, world C\n");
+ pr_warn("Hello, world C, faking module B\n");
}
-EXPORT_SYMBOL(printC);
+EXPORT_SYMBOL(printB);
MODULE_AUTHOR("Lucas De Marchi <lucas.demarchi@xxxxxxxxx>");
MODULE_LICENSE("GPL");
---->8---------------
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
