From: Ilya Leoshkevich <iii@linux.ibm.com>
To: sashiko-reviews@lists.linux.dev
Cc: Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH] s390/irqflags: add out-of-line definitions of arch_local_irq_*() for KMSAN
Date: Thu, 6 Aug 2026 20:38:43 +0200 [thread overview]
Message-ID: <a176a089-c6bf-4dfe-9595-f4f2f2f7066c@linux.ibm.com> (raw)
In-Reply-To: <20260806101931.53AC31F000E9@smtp.kernel.org>
On 8/6/26 12:19, sashiko-bot@kernel.org 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.
[...]
prev parent reply other threads:[~2026-08-06 18:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 10:00 [PATCH] s390/irqflags: add out-of-line definitions of arch_local_irq_*() for KMSAN Ilya Leoshkevich
2026-08-06 10:17 ` Heiko Carstens
2026-08-06 18:41 ` Ilya Leoshkevich
2026-08-06 10:19 ` sashiko-bot
2026-08-06 18:38 ` Ilya Leoshkevich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a176a089-c6bf-4dfe-9595-f4f2f2f7066c@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.