Re: [tip: objtool/core] jump_label, x86: Allow short NOPs

From: Peter Zijlstra
Date: Tue May 18 2021 - 16:24:58 EST



+kbuild maintainers

On Tue, May 18, 2021 at 09:50:04PM +0200, Peter Zijlstra wrote:
> On Wed, May 12, 2021 at 01:19:47PM -0000, tip-bot2 for Peter Zijlstra wrote:
> > The following commit has been merged into the objtool/core branch of tip:
> >
> > Commit-ID: ab3257042c26d0cd44793c741e2f89bf38b21fe8
> > Gitweb: https://git.kernel.org/tip/ab3257042c26d0cd44793c741e2f89bf38b21fe8
> > Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > AuthorDate: Thu, 06 May 2021 21:34:05 +02:00
> > Committer: Ingo Molnar <mingo@xxxxxxxxxx>
> > CommitterDate: Wed, 12 May 2021 14:54:56 +02:00
> >
> > jump_label, x86: Allow short NOPs
> >
> > Now that objtool is able to rewrite jump_label instructions, have the
> > compiler emit a JMP, such that it can decide on the optimal encoding,
> > and set jump_entry::key bit1 to indicate that objtool should rewrite
> > the instruction to a matching NOP.
> >
> > For x86_64-allyesconfig this gives:
> >
> > jl\ NOP JMP
> > short: 22997 124
> > long: 30874 90
> >
> > IOW, we save (22997+124) * 3 bytes of kernel text in hotpaths.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
> > Link: https://lore.kernel.org/r/20210506194158.216763632@xxxxxxxxxxxxx
>
> So Willy is having some trouble with this commit; for some reason his
> kernel is no longer booting in his qemu thing, but I can't reproduce.
>
> I've hacked up the below vmlinux.o validation, willy can you run this on
> your vmlinux.o, something like:
>
> build/tools/objtool/objtool check -abdJsuld build/vmlinux.o
>
> Where I'm assuming you build with O=build/. When I run it on my build
> (with your .config) I get absolutely nothing :/
>
> Alternatively, can you get me your vmlinux.o + bzImage ?
>
> Also helpful might be trying to attach gdb to the qemu gdbstub and
> looking where the boot fails.

OK, willy followed up on IRC, and it turns out there's a kbuild
dependency missing; then objtool changes we don't rebuild:

arch/x86/entry/vdso/vma.o

even though we should, this led to an unpatched 2 byte jump-label and
things went sideways. I'm not sure I understand the whole build
machinery well enough to know where to begin chasing this.

Now, this file is mighty magical, due to:

arch/x86/entry/vdso/Makefile:OBJECT_FILES_NON_STANDARD := y
arch/x86/entry/vdso/Makefile:OBJECT_FILES_NON_STANDARD_vma.o := n

Maybe that's related.