From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 440A22D94B5 for ; Thu, 25 Jun 2026 21:05:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782421502; cv=none; b=c5SWzdzaokHk0t1o7uN3YU45kBYoeU6le6sWgabgmlQ6b+ytEB4yrZraeOkzWOJj8VSW9PLU7O82q0/T0UiTbqn+aXePxT9VG3P9kRamzOakj6L1RxMlupeiFFxehdhezCDart8kGLIjQiOnjJku/bc7FaCY3RJPOjcAZRcoHGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782421502; c=relaxed/simple; bh=0QMmxqYbLSvI46PawbFV8RSIxkOPOGR+zS4gROPypZE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Hiz+C3hbCAaQvn10MQDyBATwRsadFoPtbRlCYmmKwF9nipaaTOBkDmkNZ0FpSQ/R0lytc0dUej55jLeIgn/7xgboxJG+o7JWBnzOf5sHjv+UKNqa3Y3iNqcojvpWtFeCkv5cO6FolDh/dAJ9PYTK02CjS0ar3KJgq9Kz7V5Mudo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UD22G9Ep; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UD22G9Ep" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E0FD1F000E9; Thu, 25 Jun 2026 21:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782421500; bh=RpH0Vm/Q7gmwLmG5IpN99jjaBwAqRf7eWkuGct7RiJQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=UD22G9Epu30GuABeOtwjtz/WNLunydxj1leWeGqRZxawRIgXq6tL1NOle/euT90Iw YxYsmvMTFKRGBri1L4nRvwaEjm50kkW8cydA/nxEcGWFSPR4oLPD6QIs13CtE04eYI O3UY1oM9FkRDg7RScBJcp2uNlvpPArujj/O46hPMMvmwnmmJekbj0Tu2fAWUd1GbFP KUvVBAUWgBlbe2hRsOINpXE1XV16awyliy3QPEm79mXNzBXjWmtiAV/gaIPxhYmx55 lC054PV9xvtRp33WkjMPBN7d7ah1jMX8sznK+Mzqu+/qWqAX17OxJzR+7uKuKUL1E9 Uiqh3i7OjeDgg== From: Thomas Gleixner To: Alexander Potapenko Cc: Mark Rutland , Dmitry Vyukov , syzbot , kasan-dev , 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 In-Reply-To: References: <69e7ee1f.a00a0220.17a17.001d.GAE@google.com> <87v7cu876c.ffs@tglx> <87zf246t8l.ffs@tglx> Date: Thu, 25 Jun 2026 23:04:57 +0200 Message-ID: <87v7b6jpqe.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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 > #include > #include > > @@ -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