Re: [syzbot] upstream build error (23)

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Jul 29 2025 at 15:12, Kees Cook wrote:
> On Tue, Jul 29, 2025 at 11:17:41PM +0200, Thomas Gleixner wrote:
>> > The kernel is full of such inline (not __always_inline) stub
>> > conditionals which evaluate to a constant....
>> 
>> And chasing all those stubs and convert them to __always_inline seems to
>> be a whack-a-mole game.
>> 
>> Can we just stop pretending that GCC12 is KCOV capable?
>
> That's fine by me, but I do think something weirder is happening here.
> Those efi linkages should be entirely DCE'ed?

Of course.

Though it un-inlines the stub function and slaps the sanitizer call into
it, which seems to prevent DCE to drop it:

	.type   efi_enabled.constprop.0, @function
efi_enabled.constprop.0:
.LASANPC6082:
.LFB6082:
        .file 5 "/home/tglx/work/kernel/linus/linux/include/linux/efi.h"
        .loc 5 891 20 is_stmt 1 view -0
        .cfi_startproc
.LVL13:
        .loc 5 893 2 view .LVU43
        .loc 5 893 9 is_stmt 0 view .LVU44
        call    __sanitizer_cov_trace_pc
.LVL14:
	.loc 5 894 1 view .LVU45
	xorl    %eax, %eax
	jmp     __x86_return_thunk
	.cfi_endproc

We had similar issues with function tracing in the past where different
GCC versions decided un-inlining at random places, so we ended up adding
notrace to the inline define.

Adding __no_sanitize_coverage as well is curing it for good.

Thanks,

        tglx
---
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2b77d12e07b2..46f7722039c3 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -233,7 +233,7 @@ struct ftrace_likely_data {
  * of extern inline functions at link time.
  * A lot of inline functions can cause havoc with function tracing.
  */
-#define inline inline __gnu_inline __inline_maybe_unused notrace
+#define inline inline __gnu_inline __inline_maybe_unused notrace __no_sanitize_coverage
 
 /*
  * gcc provides both __inline__ and __inline as alternate spellings of