Message-ID: <CAHk-=wjje8UdsQ_mjGVF4Bc_TcjAWRgOps7E_Cytg4xTbXfyig@mail.gmail.com>
Date:   Wed, 22 Jun 2022 12:48:54 -0500
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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@...il.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

Powered by blists - more mailing lists