linux-kernel - Re: [PATCH v2] mm/page_alloc.c: inline _

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:   Tue, 10 Oct 2017 14:45:45 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Aaron Lu <aaron.lu@...el.com>
Cc:     Dave Hansen <dave.hansen@...el.com>, linux-mm <linux-mm@...ck.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Huang Ying <ying.huang@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Kemi Wang <kemi.wang@...el.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Subject: Re: [PATCH v2] mm/page_alloc.c: inline __rmqueue()

On Tue, 10 Oct 2017 13:43:43 +0800 Aaron Lu <aaron.lu@...el.com> wrote:

> On Mon, Oct 09, 2017 at 10:19:52PM -0700, Dave Hansen wrote:
> > On 10/09/2017 07:56 PM, Aaron Lu wrote:
> > > This patch adds inline to __rmqueue() and vmlinux' size doesn't have any
> > > change after this patch according to size(1).
> > > 
> > > without this patch:
> > >    text    data     bss     dec     hex     filename
> > > 9968576 5793372 17715200  33477148  1fed21c vmlinux
> > > 
> > > with this patch:
> > >    text    data     bss     dec     hex     filename
> > > 9968576 5793372 17715200  33477148  1fed21c vmlinux
> > 
> > This is unexpected.  Could you double-check this, please?
> 
> mm/page_alloc.o has size changes:
> 
> Without this patch:
> $ size mm/page_alloc.o
>   text    data     bss     dec     hex filename
>  36695    9792    8396   54883    d663 mm/page_alloc.o
> 
> With this patch:
> $ size mm/page_alloc.o
>   text    data     bss     dec     hex filename
>  37511    9792    8396   55699    d993 mm/page_alloc.o
> 
> But vmlinux doesn't.
> 
> It's not clear to me what happened, do you want to me dig this out?

There's weird stuff going on.

With x86_64 gcc-4.8.4

Patch not applied:

akpm3:/usr/local/google/home/akpm/k/25> nm mm/page_alloc.o|grep __rmqueue
0000000000002a00 t __rmqueue

Patch applied:

akpm3:/usr/local/google/home/akpm/k/25> nm mm/page_alloc.o|grep __rmqueue
000000000000039f t __rmqueue_fallback
0000000000001220 t __rmqueue_smallest

So inlining __rmqueue has caused the compiler to decide to uninline
__rmqueue_fallback and __rmqueue_smallest, which largely undoes the
effect of your patch.

`inline' is basically advisory (or ignored) in modern gcc's.  So gcc
has felt free to ignore it in __rmqueue_fallback and __rmqueue_smallest
because gcc thinks it knows best.  That's why we created
__always_inline, to grab gcc by the scruff of its neck.

So...  I think this patch could do with quite a bit more care, tuning
and testing with various gcc versions.