Message ID | 20190927093603.9140-2-yamada.masahiro@socionext.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | module: various bug-fixes and clean-ups for module namespace | expand |
On Fri, Sep 27, 2019 at 6:37 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > Currently, external module builds produce tons of false-positives: > > WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it. > > Here, the <ns> part shows a random string. > > When you build external modules, the symbol info of vmlinux and > in-kernel modules are read from $(objtree)/Module.symvers, but > read_dump() is buggy in multiple ways: > > [1] When the modpost is run for vmlinux and in-kernel modules, > sym_extract_namespace() correctly allocates memory for the namespace. > On the other hand, read_dump() does not, then sym->namespace will > point to somewhere in the line buffer of get_next_line(). The data > in the buffer will be replaced soon, and sym->namespace will end up > with pointing to unrelated data. As a result, check_exports() will > show random strings in the warning messages. > > [2] When there is no namespace, sym_extract_namespace() returns NULL. > On the other hand, read_dump() sets namespace to an empty string "". > (but, it will be later replaced with unrelated data due to bug [1].) > The check_exports() shows a warning unless exp->namespace is NULL, > so every symbol read from read_dump() emits the warning, which is > mostly false positive. > > To address [1], I added NOFAIL(strdup(...)) to allocate memory. > For [2], I changed the if-conditional in check_exports(). > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces")
On Fri, Sep 27, 2019 at 06:35:57PM +0900, Masahiro Yamada wrote: >Currently, external module builds produce tons of false-positives: > > WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it. > >Here, the <ns> part shows a random string. > >When you build external modules, the symbol info of vmlinux and >in-kernel modules are read from $(objtree)/Module.symvers, but >read_dump() is buggy in multiple ways: > >[1] When the modpost is run for vmlinux and in-kernel modules, >sym_extract_namespace() correctly allocates memory for the namespace. >On the other hand, read_dump() does not, then sym->namespace will >point to somewhere in the line buffer of get_next_line(). The data >in the buffer will be replaced soon, and sym->namespace will end up >with pointing to unrelated data. As a result, check_exports() will >show random strings in the warning messages. > >[2] When there is no namespace, sym_extract_namespace() returns NULL. >On the other hand, read_dump() sets namespace to an empty string "". >(but, it will be later replaced with unrelated data due to bug [1].) >The check_exports() shows a warning unless exp->namespace is NULL, >so every symbol read from read_dump() emits the warning, which is >mostly false positive. > >To address [1], I added NOFAIL(strdup(...)) to allocate memory. >For [2], I changed the if-conditional in check_exports(). Thanks for addressing this. Greg had reported this earlier this week and Shaun was proposing a fix earlier today. Shaun's fix also ensures that memory is released when updating the namespace. But judging from the code around 'symbolhash' it seems that leaking this is accepted for modpost. Not sure about that. Having said that, please feel free to add Reviewed-by: Matthias Maennich <maennich@google.com> Cheers, Matthias >Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >--- > > scripts/mod/modpost.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c >index 3961941e8e7a..5c628a7d80f7 100644 >--- a/scripts/mod/modpost.c >+++ b/scripts/mod/modpost.c >@@ -2195,7 +2195,7 @@ static int check_exports(struct module *mod) > else > basename = mod->name; > >- if (exp->namespace) { >+ if (exp->namespace && exp->namespace[0]) { > add_namespace(&mod->required_namespaces, > exp->namespace); > >@@ -2453,7 +2453,7 @@ static void read_dump(const char *fname, unsigned int kernel) > mod = new_module(modname); > mod->skip = 1; > } >- s = sym_add_exported(symname, namespace, mod, >+ s = sym_add_exported(symname, NOFAIL(strdup(namespace)), mod, > export_no(export)); > s->kernel = kernel; > s->preloaded = 1; >-- >2.17.1 >
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 3961941e8e7a..5c628a7d80f7 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -2195,7 +2195,7 @@ static int check_exports(struct module *mod) else basename = mod->name; - if (exp->namespace) { + if (exp->namespace && exp->namespace[0]) { add_namespace(&mod->required_namespaces, exp->namespace); @@ -2453,7 +2453,7 @@ static void read_dump(const char *fname, unsigned int kernel) mod = new_module(modname); mod->skip = 1; } - s = sym_add_exported(symname, namespace, mod, + s = sym_add_exported(symname, NOFAIL(strdup(namespace)), mod, export_no(export)); s->kernel = kernel; s->preloaded = 1;
Currently, external module builds produce tons of false-positives: WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it. Here, the <ns> part shows a random string. When you build external modules, the symbol info of vmlinux and in-kernel modules are read from $(objtree)/Module.symvers, but read_dump() is buggy in multiple ways: [1] When the modpost is run for vmlinux and in-kernel modules, sym_extract_namespace() correctly allocates memory for the namespace. On the other hand, read_dump() does not, then sym->namespace will point to somewhere in the line buffer of get_next_line(). The data in the buffer will be replaced soon, and sym->namespace will end up with pointing to unrelated data. As a result, check_exports() will show random strings in the warning messages. [2] When there is no namespace, sym_extract_namespace() returns NULL. On the other hand, read_dump() sets namespace to an empty string "". (but, it will be later replaced with unrelated data due to bug [1].) The check_exports() shows a warning unless exp->namespace is NULL, so every symbol read from read_dump() emits the warning, which is mostly false positive. To address [1], I added NOFAIL(strdup(...)) to allocate memory. For [2], I changed the if-conditional in check_exports(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- scripts/mod/modpost.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)