Rebuilt the CC list because most people were added based on the incorrect bisect result.
On Thu, Jun 17, 2021 at 02:51:49PM +0100, Matthew Wilcox wrote:
On Thu, Jun 17, 2021 at 06:15:45PM +0530, Naresh Kamboju wrote:
On Thu, 17 Jun 2021 at 17:41, Naresh Kamboju naresh.kamboju@linaro.org wrote:
x86_64-linux-gnu-ld: mm/mremap.o: in function `move_pgt_entry': mremap.c:(.text+0x763): undefined reference to `__compiletime_assert_342'
The git bisect pointed out the first bad commit.
The first bad commit: commit 928cf6adc7d60c96eca760c05c1000cda061604e Author: Stephen Boyd swboyd@chromium.org Date: Thu Jun 17 15:21:35 2021 +1000 module: add printk formats to add module build ID to stacktraces
Your git bisect probably went astray. There's no way that commit caused that regression.
My bisect landed on commit 83f85ac75855 ("mm/mremap: convert huge PUD move to separate helper"). flush_pud_tlb_range() evaluates to BUILD_BUG() when CONFIG_TRANSPARENT_HUGEPAGE is unset but this function is present just based on the value of CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD.
$ make -skj(nproc) ARCH=x86_64 CC=clang O=build/x86_64 distclean allnoconfig mm/mremap.o
$ llvm-readelf -s build/x86_64/mm/mremap.o &| rg __compiletime_assert 21: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __compiletime_assert_337
$ rg TRANSPARENT_ build/x86_64/.config 450:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y 451:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y 562:# CONFIG_TRANSPARENT_HUGEPAGE is not set
Not sure why this does not happen on newer clang versions, presumably something with inlining decisions? Still seems like a legitimate issue to me.
Cheers, Nathan