Re: [PATCH] ubsan: disable UBSAN_DIV_ZERO for clang

From: Linus Torvalds
Date: Thu Jul 14 2022 - 19:16:01 EST

On Thu, Jul 14, 2022 at 1:56 PM Nick Desaulniers
<ndesaulniers@xxxxxxxxxx> wrote:
> Building with UBSAN_DIV_ZERO with clang produces numerous fallthrough
> warnings from objtool.

Ok, with this applied, things are better.

There are still the "__ubsan_handle_load_invalid_value() with UACCESS
enabled" messages, but those are misfeatures of the kvm cmpxchg

I'm not entirely sure why the clang build warns but gcc doesn't, but I
*think* it's because clang is just being silly. It *looks* like it
checks that a "bool" has a value range of 0/1, and will complain if

And the reason I say that's silly is that if I read it correctly, then
that value has literally been generated by clang itself, using "setz"

It's the __try_cmpxchg_user_asm() macro, and with clang-14 I have it's
that CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT case, and the C code uses
inline asm and does

asm_volatile_goto("\n" \
"1: " LOCK_PREFIX "cmpxchg"itype" %[new], %[ptr]\n"\
_ASM_EXTABLE_UA(1b, %l[label]) \
: CC_OUT(z) (success), \

where that CC_OUT() in this case turns into

# define CC_OUT(c) "=@cc" #c

and clang generates this code for it:

7d01e: f0 48 0f b1 4d 00 lock cmpxchg %rcx,0x0(%rbp)
7d024: 49 89 c5 mov %rax,%r13
7d027: 0f 94 c0 sete %al
7d02a: 41 88 c6 mov %al,%r14b
7d02d: bf 02 00 00 00 mov $0x2,%edi
7d032: 44 89 f6 mov %r14d,%esi
7d035: e8 00 00 00 00 call __sanitizer_cov_trace_const_cmp1
7d03a: 41 80 fe 01 cmp $0x1,%r14b
7d03e: 0f 87 af 01 00 00 ja 7d1f3

where that last "ja 7d1f3" is the branch to the code that then
calls __ubsan_handle_load_invalid_value.

But look at that code: it's literally

sete %al
mov %al,%r14b
cmp $0x1,%r14b

where clang has generated that "sete itself, and then it verifies that
the result is "<= 1".

IOW, clang seems to be literally just checking that the "sete"
instruction works right.

That's silly.

Maybe I'm misreading this, but I think the reason the clang build
complains, but the gcc build does not, is simply because gcc isn't
doing crazy checks of how the CPU works.

Some mis-feature of the "asm with flag output" code, where clang
doesn't understand that it generated that code itself, and the "setcc"
instruction always returns 0/1?

The old issue with "memcpy/memset() leaves .noinstr.text section"
because clang has generated out-of-line functions for trivial copies
also remains, but whatever.