On Fri, Mar 17, 2023 at 10:16 AM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> - blk-mq SRCU fix for BLK_MQ_F_BLOCKING devices (Christ)
Christ indeed.
But I think you meant "Chris".
> Side note - when doing the usual allmodconfig builds with gcc-12 and
> clang before sending them out, for the latter I see this warning being
> spewed with clang-15:
>
> drivers/media/i2c/m5mols/m5mols.o: warning: objtool: m5mols_set_fmt() falls through to next function m5mols_get_frame_desc()
>
> Obviously not related to my changes, but mentioning it in case it has
> been missed as I know you love squeaky clean builds :-). Doesn't happen
> with clang-14.
Hmm. I have clang-15 too, but I do the allmodconfig builds with gcc,
and only my own "normal config" builds with clang.
So I don't see this particular issue and my builds are still squeaky clean.
That said, when I explicitly try that allmodconfig thing with clang, I
can see it too. And the reason seems to be something we've seen
before: UBSAN functions being considered non-return by clang, so clang
generates code like this:
....
.LBB24_3:
callq __sanitizer_cov_trace_pc@PLT
movl $2, %esi
movq $.L__unnamed_3, %rdi
callq __ubsan_handle_out_of_bounds
.Lfunc_end24:
.size m5mols_set_fmt, .Lfunc_end24-m5mols_set_fmt
ie the last thing in that m5mols_set_fmt() function is a call to
__ubsan_handle_out_of_bounds, and then it "falls through" to the next
function.
And yes, I absolutely *detest* how clang does that. Not only does it
cause objtool sanity checking issues, it fundamentally means that we
can never treat UBSAN warnings as warnings. They are always fatal.
This is a *huge* clang mis-feature, and I forget what we decided last
that we saw it.
But I suspect we need to disable UBSAN for clang, because clang gets
this so *horribly* wrong.
Fatal errors that cannot be recovered from are not something that the
compiler is supposed to decide on. It's exactly the same issue as
BUG() calls: it just results in a dead machine, and in the process the
actual problem easily gets lost (because maybe this only happens while
running X, and no serial console, and no way to actually see what the
UBSAN warning was as a result).
I really really detest this thing, and I think this is a fatal flaw,
and means that as-is, UBSAN really *has* to be disabled for clang
kernel builds. Maybe that will make somebody wake up and smell the
roses, and stop this idiotic "undefined behavior is fatal" garbage.
Nick? Do you remember what the fix was last time?
Linus
