linux-kernel - Re: [PATCH v3] mm, slub: change run-time assertion in kmalloc

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]

Message-ID: <20210515215647.GA61684@hyeyoo>
Date:   Sun, 16 May 2021 06:56:47 +0900
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     akpm@...ux-foundation.org, iamjoonsoo.kim@....com,
        rientjes@...gle.com, penberg@...nel.org, cl@...ux.com,
        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 Sat, May 15, 2021 at 11:24:25PM +0200, Vlastimil Babka wrote:
>
> That's a misunderstanding. __kmalloc() is not a dummy function, you
> probably found only the header declaration.
>

Sorry, that was totally my misunderstanding.
I was reading dummy function in arch/alpha/boot/bootpz.c:415.
I wrongly configured the tool.

> 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".

That is what I was missing. Thank you for kindly explaining it.

> 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?

Fixing clang's bug in linux kernel doesn't seem to be a solution.
So now I understand why Nathan said we might require LLVM > 11.

I thought I should do something to fix it because I sent the patch.
but I was misunderstanding a lot. Thank you sincerely for letting me know.

Thanks,

Hyeonggon