| Message ID | 20210713152100.10381-5-mgorman@techsingularity.net (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | 5.14-rc1 mm/page_alloc.c stray patches | expand |
On 7/13/21 8:21 AM, Mel Gorman wrote: > From: Matteo Croce <mcroce@microsoft.com> > > This reverts commit f7173090033c70886d925995e9dfdfb76dbb2441. > > Fix an unresolved symbol error when CONFIG_DEBUG_INFO_BTF=y: > > LD vmlinux > BTFIDS vmlinux > FAILED unresolved symbol should_fail_alloc_page > make: *** [Makefile:1199: vmlinux] Error 255 > make: *** Deleting file 'vmlinux' Yes! I ran into this yesterday. Your patch fixes this build failure for me, so feel free to add: Tested-by: John Hubbard <jhubbard@nvidia.com> However, I should add that I'm still seeing another build failure, after fixing the above: LD vmlinux BTFIDS vmlinux FAILED elf_update(WRITE): no error make: *** [Makefile:1176: vmlinux] Error 255 make: *** Deleting file 'vmlinux' ...and un-setting CONFIG_DEBUG_INFO_BTF makes that disappear. Maybe someone who is understands the BTFIDS build step can shed some light on that; I'm not there yet. :) thanks,
Cc. Jiri Olsa + Arnaldo On 14/07/2021 09.06, John Hubbard wrote: > On 7/13/21 8:21 AM, Mel Gorman wrote: >> From: Matteo Croce <mcroce@microsoft.com> >> >> This reverts commit f7173090033c70886d925995e9dfdfb76dbb2441. >> >> Fix an unresolved symbol error when CONFIG_DEBUG_INFO_BTF=y: >> >> LD vmlinux >> BTFIDS vmlinux >> FAILED unresolved symbol should_fail_alloc_page >> make: *** [Makefile:1199: vmlinux] Error 255 >> make: *** Deleting file 'vmlinux' > > Yes! I ran into this yesterday. Your patch fixes this build failure > for me, so feel free to add: > > Tested-by: John Hubbard <jhubbard@nvidia.com> > > > However, I should add that I'm still seeing another build failure, after > fixing the above: > > LD vmlinux > BTFIDS vmlinux > FAILED elf_update(WRITE): no error This elf_update(WRITE) error is new to me. > make: *** [Makefile:1176: vmlinux] Error 255 > make: *** Deleting file 'vmlinux' It is annoying that vmlinux is deleted in this case, because I usually give Jiri the output from 'resolve_btfids -v' on vmlinux. $ ./tools/bpf/resolve_btfids/resolve_btfids -v vmlinux.failed You can do: $ git diff diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index 3b261b0f74f0..02dec10a7d75 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -302,7 +302,8 @@ cleanup() rm -f .tmp_symversions.lds rm -f .tmp_vmlinux* rm -f System.map - rm -f vmlinux + # rm -f vmlinux + mv vmlinux vmlinux.failed rm -f vmlinux.o } > > > ...and un-setting CONFIG_DEBUG_INFO_BTF makes that disappear. Maybe someone > who is understands the BTFIDS build step can shed some light on that; I'm > not there yet. :) I'm just a user/consume of output from the BTFIDS build step, I think Jiri Olsa own the tool resolve_btfids, and ACME pahole. I've hit a number of issues in the past that Jiri and ACME help resolve quickly. The most efficient solution I've found was to upgrade pahole to a newer version. What version of pahole does your build system have? What is your GCC version? --Jesper
... >> LD vmlinux >> BTFIDS vmlinux >> FAILED elf_update(WRITE): no error > > This elf_update(WRITE) error is new to me. > >> make: *** [Makefile:1176: vmlinux] Error 255 >> make: *** Deleting file 'vmlinux' > > It is annoying that vmlinux is deleted in this case, because I usually give Jiri the output from > 'resolve_btfids -v' on vmlinux. > > $ ./tools/bpf/resolve_btfids/resolve_btfids -v vmlinux.failed > > You can do: > $ git diff > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index 3b261b0f74f0..02dec10a7d75 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -302,7 +302,8 @@ cleanup() > rm -f .tmp_symversions.lds > rm -f .tmp_vmlinux* > rm -f System.map > - rm -f vmlinux > + # rm -f vmlinux > + mv vmlinux vmlinux.failed > rm -f vmlinux.o > } > > >> >> >> ...and un-setting CONFIG_DEBUG_INFO_BTF makes that disappear. Maybe someone >> who is understands the BTFIDS build step can shed some light on that; I'm >> not there yet. :) > > I'm just a user/consume of output from the BTFIDS build step, I think Jiri Olsa own the tool > resolve_btfids, and ACME pahole. I've hit a number of issues in the past that Jiri and ACME help > resolve quickly. > The most efficient solution I've found was to upgrade pahole to a newer version. > > What version of pahole does your build system have? > > What is your GCC version? > Just a quick answer first on the versions: this is an up to date Arch Linux system: gcc: 11.1.0 pahole: 1.21 I'll try to get the other step done later this evening. thanks,
On 7/15/21 5:04 PM, John Hubbard wrote: ... >>> ...and un-setting CONFIG_DEBUG_INFO_BTF makes that disappear. Maybe someone >>> who is understands the BTFIDS build step can shed some light on that; I'm >>> not there yet. :) >> >> I'm just a user/consume of output from the BTFIDS build step, I think Jiri Olsa own the tool >> resolve_btfids, and ACME pahole. I've hit a number of issues in the past that Jiri and ACME help >> resolve quickly. >> The most efficient solution I've found was to upgrade pahole to a newer version. >> >> What version of pahole does your build system have? >> >> What is your GCC version? >> > > Just a quick answer first on the versions: this is an up to date Arch Linux system: > > gcc: 11.1.0 > pahole: 1.21 > > I'll try to get the other step done later this evening. ...and...I've lost the repro completely. The only thing I changed was that I attempted to update pahole. This caused Arch Linux reinstall pahole, claiming that 1.21 is already the current version. It acts as if there was something wrong with the pahole installation. This seems unlikely, given that the system is merely on a routine update schedule. However, that's the data I have. If it ever comes up again I'll be able to run resolve_btfids, using your steps here, so thanks for posting those! thanks,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c66f1e6204c2..3e97e68aef7a 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3820,7 +3820,7 @@ static inline bool __should_fail_alloc_page(gfp_t gfp_mask, unsigned int order) #endif /* CONFIG_FAIL_PAGE_ALLOC */ -static noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order) +noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order) { return __should_fail_alloc_page(gfp_mask, order); }