linux-kernel - Re: build failure caused by RUNTIME

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: <CAHk-=wguPQZKfWdNjF8OedfttMNkrW57Kb5Wjv0NmTzoEbUG7A@mail.gmail.com>
Date: Fri, 2 Aug 2024 09:50:28 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: build failure caused by RUNTIME_CONST()

On Fri, 2 Aug 2024 at 04:45, Oleg Nesterov <oleg@...hat.com> wrote:
>
> make bzImage results in
>
>         undefined reference to `__start_runtime_shift_d_hash_shift'
>         undefined reference to `__stop_runtime_shift_d_hash_shift'
>         undefined reference to `__start_runtime_ptr_dentry_hashtable'
>         undefined reference to `__stop_runtime_ptr_dentry_hashtable'

Grr.

> The patch below seems to fix the problem, but I didn't find any report on lkml,
> so perhaps I am the only one which hits this problem? And perhaps this is because
> my gcc 5.3.1 is quite old?

It's not your gcc. It must be your linker that is old and decrepit.

> OTOH, I know nothing about lds magic, so I fail to understand where these
> __start/stop_runtime_xxx can come from without something like the change below...

So it comes from this:

    https://sourceware.org/binutils/docs/ld/Input-Section-Example.html

and in there you will find

   "If an output section’s name is the same as the input section’s name
    and is representable as a C identifier, then the linker will
    automatically see PROVIDE two symbols: __start_SECNAME and
    __stop_SECNAME, where SECNAME is the name of the section. These
    indicate the start address and end address of the output section
    respectively"

but apparently your linker doesn't do that.

I guess we'll have to go with doing this manually as in your patch,
but can you say what your linker version is so that I can curse it in
private and document it in public?

And yes, I think you must be one of the very few users of it, because
I too am not finding any other reports on lore (or with a wider google
search),

                  Linus