The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Alexander Potapenko <glider@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	syzbot <syzbot+cdcfd55737fe43eeb3a3@syzkaller.appspotmail.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	linux-kernel@vger.kernel.org, luto@kernel.org,
	peterz@infradead.org, syzkaller-bugs@googlegroups.com,
	ruanjinjie@huawei.com
Subject: Re: [syzbot] [kernel?] upstream test error: KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt
Date: Thu, 25 Jun 2026 23:04:57 +0200	[thread overview]
Message-ID: <87v7b6jpqe.ffs@fw13> (raw)
In-Reply-To: <CAG_fn=U19e7VcRRx53XXTwJab+479M62aOU71TYPzaJAtjtnkA@mail.gmail.com>

On Tue, Jun 09 2026 at 15:34, Alexander Potapenko wrote:
>> So let me finally take a stab at it.
>
> Hi Thomas,
>
> I have a draft Clang patch implementing the following intrinsics at
> https://github.com/llvm/llvm-project/pull/202603:
> - llvm.kmsan.instrumentation.begin
> - llvm.kmsan.instrumentation.end
> - llvm.kmsan.instrumentation.update.context (to reload the context
> pointer; I am not using it yet).
>
> Below is the kernel patch that I am applying to insert these
> intrinsics into the instrumentation regions.
> I thought it would be a good idea to warn if
> llvm.kmsan.instrumentation.{begin,end} are called from functions that
> are fully instrumented or have `no_sanitize("memory")` (aka
> __no_kmsan_checks), but surprisingly, there were loads of such
> functions.
>
> It turned out that WARN() and BUG() unconditionally invoke
> instrumentation_begin() and instrumentation_end(), even for
> instrumented functions.
> Was there any long-term plan to fix that, or is my warning useless by design?

The reason why e.g. WARN() and BUG() unconditionally do that is that we
decided that getting out the WARN/BUG information has priority and IIRC
we mostly did that to shut the objtool noinstr validation up. There is a
halfways comprehensible comment in x86...bug.h:

/*
 * This instrumentation_begin() is strictly speaking incorrect; but it
 * suppresses the complaints from WARN()s in noinstr code. If such a WARN()
 * were to trigger, we'd rather wreck the machine in an attempt to get the
 * message out than not know about it.
 */

It could be fixed by having some special version of BUG/WARN() which will
be a bit of a whack a mole game, but if it helps to make the sanitizers
saner, then that's probably worth it.

> Patch follows:
> ```
> diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h
> index bf675a8aef8ab..49a2ee638120b 100644
> --- a/include/linux/instrumentation.h
> +++ b/include/linux/instrumentation.h
> @@ -4,6 +4,7 @@
>
>  #ifdef CONFIG_NOINSTR_VALIDATION
>
> +#include <linux/kmsan-checks.h>
>  #include <linux/objtool.h>
>  #include <linux/stringify.h>
>
> @@ -12,6 +13,7 @@
>   asm volatile(__stringify(c) ": nop\n\t" \
>        ANNOTATE_INSTR_BEGIN(__ASM_BREF(c)) \
>        : : "i" (c)); \
> + kmsan_instrumentation_begin(); \
>  })
>  #define instrumentation_begin() __instrumentation_begin(__COUNTER__)
>
> @@ -47,6 +49,7 @@
>   * part of the condition block and does not escape.
>   */
>  #define __instrumentation_end(c) ({ \
> + kmsan_instrumentation_end(); \
>   asm volatile(__stringify(c) ": nop\n\t" \
>        ANNOTATE_INSTR_END(__ASM_BREF(c)) \
>        : : "i" (c)); \

Looks very reasonable.

Thanks for looking into this!

       tglx

  parent reply	other threads:[~2026-06-25 21:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 21:37 [syzbot] [kernel?] upstream test error: KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt syzbot
2026-04-29  6:29 ` Dmitry Vyukov
2026-04-29  8:09   ` Alexander Potapenko
2026-05-11 12:25     ` Thomas Gleixner
2026-05-12  9:33       ` Alexander Potapenko
2026-05-12 11:15         ` Mark Rutland
2026-05-12 16:24           ` Alexander Potapenko
2026-05-12 17:46             ` Mark Rutland
2026-05-22  6:26               ` Alexander Potapenko
2026-06-02 11:53                 ` Mark Rutland
2026-05-13  0:36             ` Thomas Gleixner
2026-05-13  7:54               ` Peter Zijlstra
2026-05-27 12:39               ` Alexander Potapenko
2026-06-09 13:34                 ` Alexander Potapenko
2026-06-22  9:37                   ` Alexander Potapenko
2026-06-25 21:06                     ` Thomas Gleixner
2026-06-25 21:04                   ` Thomas Gleixner [this message]
2026-06-25 20:54                 ` Thomas Gleixner

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=87v7b6jpqe.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=ruanjinjie@huawei.com \
    --cc=syzbot+cdcfd55737fe43eeb3a3@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox