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@xxxxxxxxxx> 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@xxxxxxxxxxxx>
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.