linux-kernel - Re: [PATCH 1/2] futex: mark futex_detect

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]

Date:   Thu, 7 Mar 2019 18:07:56 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Joe Perches <joe@...ches.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Elena Reshetova <elena.reshetova@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

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