linux-kernel - Re: [PATCH 10/27] modpost: traverse unresolved symbols in order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOdnysRX_qp1KYSd331G7K863iH-Xiw3UOwKRSQm65u9i-Q@mail.gmail.com>
Date:   Tue, 26 Apr 2022 10:08:25 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH 10/27] modpost: traverse unresolved symbols in order

On Sun, Apr 24, 2022 at 12:09 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> Currently, modpost manages unresolved in a singly liked list; it adds

s/liked/linked/

> a new node to the head, and traverses the list from new to old.
>
> Use a doubly linked list to keep the order in the symbol table in the
> ELF file.
>
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
>
>  scripts/mod/modpost.c | 20 ++++++++++++++------
>  scripts/mod/modpost.h |  2 +-
>  2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 1c7d2831e89d..e1eb188d6282 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -185,6 +185,8 @@ static struct module *new_module(const char *modname)
>         mod = NOFAIL(malloc(sizeof(*mod) + strlen(modname) + 1));
>         memset(mod, 0, sizeof(*mod));
>
> +       INIT_LIST_HEAD(&mod->unresolved_symbols);
> +
>         strcpy(mod->name, modname);
>         mod->is_vmlinux = (strcmp(modname, "vmlinux") == 0);
>         mod->gpl_compatible = true;
> @@ -201,6 +203,7 @@ static struct module *new_module(const char *modname)
>
>  struct symbol {
>         struct symbol *next;
> +       struct list_head list;

Isn't `list` meant to replace `next`?

>         struct module *module;
>         unsigned int crc;
>         bool crc_valid;
> @@ -255,8 +258,12 @@ static struct symbol *new_symbol(const char *name, struct module *module,
>
>  static void sym_add_unresolved(const char *name, struct module *mod, bool weak)
>  {
> -       mod->unres = alloc_symbol(name, mod->unres);
> -       mod->unres->weak = weak;
> +       struct symbol *sym;
> +
> +       sym = alloc_symbol(name, NULL);
> +       sym->weak = weak;
> +
> +       list_add_tail(&sym->list, &mod->unresolved_symbols);

Because I was curious here why NULL was passed, rather than remove the
assignment to struct symbol's next member in alloc_symbol.

I get why you replace the `unres` member of struct module. I guess I'm
curious then why yet another list is added to struct symbol, rather
than replace the next member.

Also, does adding a struct list_head member really not specify the
_type_ of the next element?  I guess when I look at the definition of
struct module, at the member unresolved symbols, I don't know whether
it's a list of struct module* or a list of struct symbol*.

<snip>

> diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
> index c3b5d2f0e2bb..6a90bfc08458 100644
> --- a/scripts/mod/modpost.h
> +++ b/scripts/mod/modpost.h
> @@ -117,7 +117,7 @@ struct namespace_list {
>  struct module {
>         struct list_head list;
>         int gpl_compatible;
> -       struct symbol *unres;
> +       struct list_head unresolved_symbols;
>         bool from_dump;         /* true if module was loaded from *.symvers */
>         bool is_vmlinux;
>         bool seen;
> --
> 2.32.0
>


-- 
Thanks,
~Nick Desaulniers