From: Dave Hansen <dave.hansen@intel.com>
To: Alexander Potapenko <glider@google.com>
Cc: elver@google.com, dvyukov@google.com,
dave.hansen@linux.intel.com, peterz@infradead.org,
akpm@linux-foundation.org, x86@kernel.org,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [PATCH 2/3] lib/Kconfig.debug: disable LOCK_DEBUGGING_SUPPORT under KMSAN
Date: Fri, 21 Jun 2024 09:23:25 -0700 [thread overview]
Message-ID: <5a38bded-9723-4811-83b5-14e2312ee75d@intel.com> (raw)
In-Reply-To: <20240621094901.1360454-2-glider@google.com>
On 6/21/24 02:49, Alexander Potapenko wrote:
> config LOCK_DEBUGGING_SUPPORT
> bool
> - depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
> + depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT && !KMSAN
> default y
This kinda stinks. Practically, it'll mean that anyone turning on KMSAN
will accidentally turn off lockdep. That's really nasty, especially for
folks who are turning on debug options left and right to track down
nasty bugs.
I'd *MUCH* rather hide KMSAN:
config KMSAN
bool "KMSAN: detector of uninitialized values use"
depends on HAVE_ARCH_KMSAN && HAVE_KMSAN_COMPILER
depends on DEBUG_KERNEL && !KASAN && !KCSAN
depends on !PREEMPT_RT
+ depends on !LOCKDEP
Because, frankly, lockdep is way more important than KMSAN.
But ideally, we'd allow them to coexist somehow. Have we even discussed
the problem with the lockdep folks? For instance, I'd much rather have
a relaxed lockdep with no checking in pfn_valid() than no lockdep at all.
next prev parent reply other threads:[~2024-06-21 16:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 9:48 [PATCH 1/3] x86: mm: disable KMSAN instrumentation for physaddr.c Alexander Potapenko
2024-06-21 9:49 ` [PATCH 2/3] lib/Kconfig.debug: disable LOCK_DEBUGGING_SUPPORT under KMSAN Alexander Potapenko
2024-06-21 15:02 ` Kirill A . Shutemov
2024-06-21 16:16 ` Dave Hansen
2024-06-21 16:23 ` Dave Hansen [this message]
2024-06-25 18:51 ` Boqun Feng
2024-06-25 19:06 ` Paul E. McKenney
2024-06-25 19:37 ` Boqun Feng
2024-06-26 8:35 ` Alexander Potapenko
2024-06-21 9:49 ` [PATCH 3/3] x86/traps: fix an objtool warning in handle_bug() Alexander Potapenko
2024-06-21 15:09 ` Kirill A . Shutemov
2024-06-21 14:57 ` [PATCH 1/3] x86: mm: disable KMSAN instrumentation for physaddr.c Kirill A . Shutemov
2024-06-21 16:40 ` Dave Hansen
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=5a38bded-9723-4811-83b5-14e2312ee75d@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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