linux-kernel - Re: [PATCH] x86/numa_emulation: Fix uniform size build failure

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] [day] [month] [year] [list]

Date:   Fri, 6 Jul 2018 09:06:59 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     David Rientjes <rientjes@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wei Yang <richard.weiyang@...il.com>,
        kbuild test robot <lkp@...el.com>, X86 ML <x86@...nel.org>,
        Linux MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/numa_emulation: Fix uniform size build failure

On Fri, Jul 6, 2018 at 3:03 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Dan Williams <dan.j.williams@...el.com> wrote:
>
>> > config attached.
>
> Doh, I intended to attach the config - attached now.
>
>> > These numa_emulation changes are a bit of a trainwreck - I'm removing both
>> > num_emulation commits from -tip for now, could you please resubmit a fixed/tested
>> > combo version?
>>
>> So I squashed the fix and let the 0day robot chew on it all day with no reports
>> as of yet. I just recompiled it here and am not seeing the link failure, can you
>> send me the details of the kernel config + gcc version that is failing?
>
> My guess: it's some weird Kconfig combination in this 32-bit config.
>
> Can you reproduce it with this config?

Yup, got it, thanks!

Turning on debuginfo I get:

arch/x86/mm/numa_emulation.o: In function `split_nodes_size_interleave_uniform':
arch/x86/mm/numa_emulation.c:257: undefined reference to `__udivdi3'

Previously we were dividing by a power-of-2 constant MAX_NUM_NODES,
and I believe in my builds the compiler was still deducing the
constant from the "nr_nodes = MAX_NUM_NODES" assignment. Fix inbound,
and I believe it will make it even clearer the difference between the
typical split and the new uniform split capability.