linux-kernel - Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO

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:   Sat, 3 Nov 2018 22:25:14 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nikolay Borisov <nborisov@...e.com>
Cc:     Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>,
        Changbin Du <changbin.du@...il.com>,
        Anand Jain <anand.jain@...cle.com>,
        Misono Tomohiro <misono.tomohiro@...fujitsu.com>,
        Qu Wenruo <wqu@...e.com>, Gu Jinxiang <gujx@...fujitsu.com>,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO_INLINE

On 11/3/18, Nikolay Borisov <nborisov@...e.com> wrote:
> On 3.11.18 г. 17:39 ч., Arnd Bergmann wrote:
>> On 32-bit ARM with gcc-8, I see a link error with the addition of the
>> CONFIG_NO_AUTO_INLINE option:
>>
>> fs/btrfs/super.o: In function `btrfs_statfs':
>> super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod'
>> fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to
>> `__aeabi_uldivmod' follow
>>
>> So far this is the only file that shows the behavior, so I'd propose
>> to just work around it by marking the functions as 'static inline'
>> that normally get inlined here.
>>
>> The reference to __aeabi_uldivmod comes from a div_u64() which has an
>> optimization for a constant division that uses a straight '/' operator
>> when the result should be known to the compiler. My interpretation is
>> that as we turn off inlining, gcc still expects the result to be constant
>> but fails to use that constant value.
>
> I read this as "this is a compiler bug", no ? So you are providing a
> hack around a compiler bug?

Mostly, yes. The do_div() macro is really pushing the boundaries
of what we can expect the compiler to do in terms of optimizations,
and we've had problems with it in the past.

IIRC the gcc developers would not classify this as a bug because
the result of __builtin_constant_p() is not guaranteed to work the
way we expect, it just does so most of the time.

        Arnd