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

From: Russell King - ARM Linux admin
Date: Thu Mar 07 2019 - 13:08:21 EST


On Thu, Mar 07, 2019 at 09:42:40AM -0800, Joe Perches wrote:
> On Thu, 2019-03-07 at 17:25 +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Mar 07, 2019 at 09:19:04AM -0800, Joe Perches wrote:
> > > On Thu, 2019-03-07 at 10:14 +0100, Arnd Bergmann 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'
> > > >
> > > > As far as I can tell, the problem is that a branch is over 16MB
> > > > apart in those configurations, but only if it branches back to
> > > > the init text.
> > > >
> > > > Marking the futex_detect_cmpxchg() function as noinline and
> > > > not __init avoids the problem for me.
> > >
> > > Perhaps the __init and __exit #defines should be noinline
> > > to allow discarding of the code.
> >
> > How does that help this case?
>
> It doesn't particularly.
> It does help any other case that might arise.

Please describe what "any other case" you are thinking of - as already
stated, your patch would have no beneficial effect for the observed
issue.

In fact, it _could_ do exactly the opposite. Where functions can be
inlined, they may become smaller due to no need for function prologue
and epilogue, and other optimisations. Forcing the compiler to avoid
inlining them could result in larger code, which means a higher chance
of triggering the "relocation truncated to fit" problem.

The converse is also a possibility too - it all depends on the inlining
behaviour of the compiler towards static functions, and the resulting
size of the code.

What may be right for one architecture and compiler may not be right
for another.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up