Re: [PATCH] s390/irqflags: add out-of-line definitions of arch_local_irq_*() for KMSAN

On 8/6/26 12:19, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Missing KMSAN attributes on the `extern` declarations of `arch_local_save_flags` and `arch_local_irq_save` will cause spurious use-of-uninitialized-value reports.

[...]

>> -#ifdef CONFIG_KMSAN
>> -#define arch_local_irq_attributes noinline notrace __no_sanitize_memory __maybe_unused
>> +#if defined(CONFIG_KMSAN) && !defined(__DECOMPRESSOR)
>> +extern unsigned long arch_local_save_flags(void);
>> +extern unsigned long arch_local_irq_save(void);
> 
> [Severity: High]
> Since these extern declarations lack KMSAN attributes, will instrumented
> callers expect a populated return value shadow in __msan_retval_tls?
> 
> When arch_local_save_flags() and arch_local_irq_save() are called from
> instrumented code, the caller reads __msan_retval_tls. However, because the
> corresponding definitions are marked noinstr:
> 
> arch/s390/kernel/irqflags.c:
> noinstr unsigned long arch_local_save_flags(void)
> {
> 	return __arch_local_save_flags();
> }
> 
> instrumentation is skipped, and __msan_retval_tls is never populated before
> returning to the caller.
> 
> Could this result in spurious use-of-uninitialized-value reports on every
> IRQ state check or lock operation (like spin_lock_irqsave) when the kernel
> is built with CONFIG_KMSAN?

This is a known issue that affects many other places.
It can be resolved by compiling with KMSAN_CHECK_PARAM_RETVAL:


lib/Kconfig.kmsan:
------------------
Disabling KMSAN_CHECK_PARAM_RETVAL will result in tracking shadow for
function parameters and return values across function borders. This
is a more relaxed mode, but it generates more instrumentation code and
may potentially report errors in corner cases when non-instrumented
functions call instrumented ones.


LLVM refers to this as "EagerChecks" internally.

[...]