Pointer for dump filename can be NULL when a module is not created from
a dump file in modpost. The find_module() function should therefore
check whether the dump filename pointers are NULL before comparing them
using strcmp().

Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
---
 scripts/mod/modpost.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 5ca7c268294e..9a64d0a55f89 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -178,8 +178,12 @@ static struct module *find_module(const char *filename, const char *modname)
 	struct module *mod;
 
 	list_for_each_entry(mod, &modules, list) {
-		if (!strcmp(mod->dump_file, filename) &&
-		    !strcmp(mod->name, modname))
+		if (strcmp(mod->name, modname) != 0)
+			continue;
+		if (!mod->dump_file && !filename)
+			return mod;
+		if (mod->dump_file && filename &&
+		    !strcmp(mod->dump_file, filename))
 			return mod;
 	}
 	return NULL;
-- 
2.50.0.727.gbf7dc18ff4-goog

On Mon, Jul 7, 2025 at 6:09 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
>
> Pointer for dump filename can be NULL when a module is not created from
> a dump file in modpost. The find_module() function should therefore
> check whether the dump filename pointers are NULL before comparing them
> using strcmp().

I do not understand.
I do not think that scenario would happen.

There are two call-sites for new_module():
[1] https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L1576
[2] https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L2117


For [2], mod->dump_file is set in the next line.

[1] is always called after read_dump(), where
is the only user of find_module(). [3]

[3]: https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L2115






> Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
> ---
>  scripts/mod/modpost.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 5ca7c268294e..9a64d0a55f89 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -178,8 +178,12 @@ static struct module *find_module(const char *filename, const char *modname)
>         struct module *mod;
>
>         list_for_each_entry(mod, &modules, list) {
> -               if (!strcmp(mod->dump_file, filename) &&
> -                   !strcmp(mod->name, modname))
> +               if (strcmp(mod->name, modname) != 0)
> +                       continue;
> +               if (!mod->dump_file && !filename)
> +                       return mod;
> +               if (mod->dump_file && filename &&
> +                   !strcmp(mod->dump_file, filename))
>                         return mod;
>         }
>         return NULL;
> --
> 2.50.0.727.gbf7dc18ff4-goog
>


-- 
Best Regards
Masahiro Yamada

On Mon, Jul 7, 2025 at 11:25 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Mon, Jul 7, 2025 at 6:09 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
> >
> > Pointer for dump filename can be NULL when a module is not created from
> > a dump file in modpost. The find_module() function should therefore
> > check whether the dump filename pointers are NULL before comparing them
> > using strcmp().
>
> I do not understand.
> I do not think that scenario would happen.
>
> There are two call-sites for new_module():
> [1] https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L1576
> [2] https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L2117
>
>
> For [2], mod->dump_file is set in the next line.
>
> [1] is always called after read_dump(), where
> is the only user of find_module(). [3]
>
> [3]: https://github.com/torvalds/linux/blob/v6.15/scripts/mod/modpost.c#L2115

I see that this is not broken at the moment.

I was working on a patch series where I am making use of find_module() after
read_symbols() is called on vmlinux and other object files for modules. I
realised that find_module() does not work as expected and decided to send a fix
generally. If you think find_module() does not need to support the general case
of finding modules after read_symbols(), I can keep this change in my patch
series and not submit it separately.

--
Regards,
Sid