Re: [PATCH 00/21] objtool: vmlinux.o and CLANG LTO support

From: Josh Poimboeuf
Date: Mon Jan 18 2021 - 12:28:12 EST

On Thu, Jan 14, 2021 at 04:41:28PM -0800, Sami Tolvanen wrote:
> I can confirm that all the warnings I previously saw are now fixed,
> but I'm seeing a few new ones:
> vmlinux.o: warning: objtool: balance_leaf_when_delete()+0x17d4: stack state mismatch: cfa1=7+192 cfa2=7+176
> vmlinux.o: warning: objtool: internal_move_pointers_items()+0x9f7: stack state mismatch: cfa1=7+160 cfa2=7+176

These seem legit stack state mismatches (compiler bug). Two code
blocks, with different stack sizes, transfer control to the same
noreturn block (violating DWARF/ORC expectation that each instruction
has a deterministic stack layout). In both cases the noreturn block has
a call to __reiserfs_panic().

> vmlinux.o: warning: objtool: strncpy_from_user()+0x181: call to do_strncpy_from_user() with UACCESS enabled
> vmlinux.o: warning: objtool: strnlen_user()+0x12b: call to do_strnlen_user() with UACCESS enabled

It's odd that Clang wouldn't inline these static single-called
functions. I could '__always_inline' them, but is this expected

> vmlinux.o: warning: objtool: i915_gem_execbuffer2_ioctl()+0x390: call to __ubsan_handle_negate_overflow() with UACCESS enabled

PeterZ, have you seen this one?

> vmlinux.o: warning: objtool: .text.snd_trident_free_voice: unexpected end of section

Another weird compiler issue. It generates obviously dead code which
jumps off the end of the function:

f7: b0 01 mov $0x1,%al
f9: 84 c0 test %al,%al
fb: 0f 84 79 05 00 00 je 67a <snd_trident_free_voice+0x67a>