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.
Cheers,
Nathan
