Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 22 Jun 2022 12:48:54 -0500 | Subject | Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support") |
| |
On Wed, Jun 22, 2022 at 12:26 PM Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > > Tried it after applying your patch. There was no build failure, but some warnings:
So some of those objtool warnings are, I think, because clang does odd and crazy things for when it decides "this is not reachable" code.
I don't much like it, and neither does objtool, but it is what it is. When clang decides "I'm calling a function that cannot return", it will have a "call" instruction and then it will just fall off the face of the earth after that.
That includes falling through to the next function, or just to random other labels after the function, and then objtool as a result complains about a stack state mismatch (when the fallthrough is the same function, but now the stack pointer is different in different parts), or of the "falls through to next function".
I think it's a clang misfeature in that if something goes wrong, you basically execute random code. I'd much rather see clang insert a real 'ud' instruction or 'int3' or whatever. But it doesn't.
I didn't check whether gcc avoids that "don't make assumptions about non-return functions" or whether it's just that objtool recognizes whatever pattern gcc uses.
So *some* of the warnings are basically code generation disagreements, but aren't signs of actual problems per se.
Others may be because objdump knows about gcc foibles in ways it doesn't know about some clang foibles. I think the "call to memcpy() leaves .noinstr.text section" might be of that type: clang seems to sometimes generate out-of-line memcpy calls for absolutely ridiculous things (I've seen a 16-byte memcpy done that way - just stupid when it's just two load/store pairs, and just the function call overhead is much more than that).
And then a couple seem to be real mis-features in our code:
> arch/x86/kvm/kvm.o: warning: objtool: emulator_cmpxchg_emulated+0x705: call to __ubsan_handle_load_invalid_value() with UACCESS enabled > arch/x86/kvm/kvm.o: warning: objtool: paging64_update_accessed_dirty_bits+0x39e: call to __ubsan_handle_load_invalid_value() with UACCESS enabled > arch/x86/kvm/kvm.o: warning: objtool: paging32_update_accessed_dirty_bits+0x390: call to __ubsan_handle_load_invalid_value() with UACCESS enabled > arch/x86/kvm/kvm.o: warning: objtool: ept_update_accessed_dirty_bits+0x43f: call to __ubsan_handle_load_invalid_value() with UACCESS enabled
and I actually sent email to the kvm and x86 people involved in those code sequences. It's the __try_cmpxchg_user() macro that isn't great.
Not a fatal problem, but a sign of something we should do better, and that one doesn't seem to be due to any actual clang misfeature.
> The build took 16 minutes 6 seconds on the build machines in my office (Codethink).
Oh yeah. I'm on a laptop that is a few years old (good laptop, just not top-of-the-line any more), and it's been chugging along for almost two hours by now. It's still working on it, and making "solid progress". But it does not seem to have hit any other failures after that memcpy fixlet, so I guess I will get to that successful end some time soon.
I don't typically do allmodconfig builds while on the road, much less with clang. With gcc, I seem to recall it being a bit over an hour. Clang is worse.
Linus
| |