Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Thu, Mar 7, 2019 at 7:21 PM Nathan Chancellor
<natechancellor@xxxxxxxxx> wrote:
>
> On Thu, Mar 07, 2019 at 10:12:11AM -0800, Nick Desaulniers wrote:
> > On Thu, Mar 7, 2019 at 1:15 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > >
> > > On 32-bit ARM, I got a link failure in futex_init() when building
> > > with clang in some random configurations:
> > >
> > > kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text'
> >
> > Do we know what function from the fixup text section is calling
> > futex_detect_cmpxchg?  I'm curious if this is maybe another case of
> > -Wsection where some function may be in the wrong section?
> >
>
> Looks like this is the call stack:
>
> futex_init ->
>     futex_detect_cmpxchg ->
>         cmpxchg_futex_value_locked ->
>             futex_atomic_cmpxchg_inatomic
>
> This is the same issue I reported: https://github.com/ClangBuiltLinux/linux/issues/325
>
> Marking arm's futex_atomic_cmpxchg_inatomic as noinline also fixes this
> so maybe that's it?

I think part of the problem is the linker sometimes failing to generate
veneers for long calls. I've seen this in the past with relocations in
non-executable sections, but it's possible that the problem here is
having a relocation to a section that doesn't start with ".text".

I have not analyzed the linker behavior in more detail, but have
experimentally shown that the problem doesn't happen if the relocation
is from the .text.fixup segment to .text rather than .init.text. It's
also possible that this is simply a result of the relative distance of
the locations in memory as Russell said, so it could come back
if the kernel grows further.

        Arnd