[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41c65455-a35b-3ad3-54f9-49ca7105bfa9@suse.cz>
Date: Sat, 15 May 2021 23:24:25 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Hyeonggon Yoo <42.hyeyoo@...il.com>, akpm@...ux-foundation.org,
iamjoonsoo.kim@....com, rientjes@...gle.com, penberg@...nel.org,
cl@...ux.com
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
nathan@...nel.org, naresh.kamboju@...aro.org,
clang-built-linux@...glegroups.com, linux-next@...r.kernel.org,
ndesaulniers@...gle.com, lkft-triage@...ts.linaro.org,
sfr@...b.auug.org.au, arnd@...db.de, Marco Elver <elver@...gle.com>
Subject: Re: [PATCH v3] mm, slub: change run-time assertion in kmalloc_index()
to compile-time
On 5/15/21 11:09 PM, Hyeonggon Yoo wrote:
> Hello Vlastimil, recently kbuild-all test bot reported compile error on
> clang 10.0.1, with defconfig.
Hm yes, catching some compiler bug was something that was noted to be
possible to happen.
> Nathan Chancellor wrote:
>> I think this happens because arch_prepare_optimized_kprobe() calls kzalloc()
>> with a size of MAX_OPTINSN_SIZE, which is
>>
>> #define MAX_OPTINSN_SIZE \
>> (((unsigned long)optprobe_template_end - \
>> (unsigned long)optprobe_template_entry) + \
>> MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE)
>
>> and the optprobe_template_{end,entry} are not evaluated as constants.
>>
>> I am not sure what the solution is. There seem to be a growing list of issues
>> with LLVM 10 that were fixed in LLVM 11, which might necessitate requiring
>> LLVM 11 and newer to build the kernel, given this affects a defconfig.
>> Cheers,
>> Nathan
>
>
> I think it's because kmalloc compiles successfully when size is constant,
> and kmalloc_index isn't. so I think compiler seems to be confused.
>
> currently if size is non-constant, kmalloc calls dummy function __kmalloc,
> which always returns NULL.
That's a misunderstanding. __kmalloc() is not a dummy function, you
probably found only the header declaration.
> so what about changing kmalloc to do compile-time assertion too, and track
> all callers that are calling kmalloc with non-constant argument.
kmalloc() is expected to be called with both constant and non-constant
size. __builtin_constant_p() is used to determine which implementation
to use. One based on kmalloc_index(), other on __kmalloc().
It appears clang 10.0.1 is mistakenly evaluating __builtin_constant_p()
as true. Probably something to do with LTO, because MAX_OPTINSN_SIZE
seems it could be a "link-time constant".
Maybe we could extend Marco Elver's followup patch that uses
BUILD_BUG_ON vs BUG() depending on size_is_constant parameter. It could
use BUG() also if the compiler is LLVM < 11 or something. What would be
the proper code for this condition?
> How do you think? If you think it is the solution, I'll do that work.
>
Powered by blists - more mailing lists