[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250804-kasan-via-kcsan-v1-0-823a6d5b5f84@google.com>
Date: Mon, 04 Aug 2025 21:17:04 +0200
From: Jann Horn <jannh@...gle.com>
To: Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas.schier@...ux.dev>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Andrew Morton <akpm@...ux-foundation.org>, Marco Elver <elver@...gle.com>,
Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, Roman Gushchin <roman.gushchin@...ux.dev>,
Harry Yoo <harry.yoo@...cle.com>
Cc: linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
kasan-dev@...glegroups.com, linux-mm@...ck.org,
Jann Horn <jannh@...gle.com>
Subject: [PATCH early RFC 0/4] running KASAN off of KCSAN's TSAN hooks
This is an experimental series for running KASAN off of KCSAN's TSAN
hooks, to allow the two modes to coexist.
The first two patches are cleanups that I think are worth landing
independently of the rest of the series.
Patch 3 implements running KASAN off of KCSAN hooks; patch 4 is a little
tweak to KCSAN's integration with SLUB.
To be transparent: This is part of a larger project I'm tinkering on; I
figured I'd send this part early since it could reasonably be useful as
a standalone feature, but my real usecase involves plumbing the data
from KCSAN further into other stuff like KCOV, and my code for that
is still very much work in progress.
If you think this feature isn't worth merging by itself, I think that'd
also be reasonable; in that case I would appreciate a very short reply
on whether this is something you'd consider merging as part of a larger
feature, or if you strongly dislike what I'm doing here.
The reason why I decided to go with running KASAN off KCSAN
instrumentation, not the other way around, is that TSAN hooks provide
more information about memory ordering properties than ASAN hooks do.
An alternate approach might be to merge ASAN and TSAN in the compiler
into one combined memory access instrumentation feature; but I don't
think my weird usecase warrants significant compiler changes at this
point.
I have checked that the KASAN unit tests (other than the ones I
explicitly disabled in my patch, and also excluding the two that are
currently failing in mainline) pass with CONFIG_KASAN_KCSAN.
The current version of this series applies on top of Linux 6.16.
Signed-off-by: Jann Horn <jannh@...gle.com>
---
Jann Horn (4):
kbuild: kasan,kcsan: refactor out enablement check
kbuild: kasan: refactor open coded cflags for kasan test
kasan: add support for running via KCSAN hooks
mm/slub: Defer KCSAN hook on free to KASAN if available
include/linux/kasan.h | 14 ++++++++++++++
kernel/kcsan/core.c | 13 +++++++++++++
lib/Kconfig.kasan | 17 +++++++++++++++++
lib/Kconfig.kcsan | 2 +-
mm/kasan/Makefile | 12 ++----------
mm/kasan/common.c | 5 +++++
mm/kasan/kasan.h | 11 -----------
mm/kasan/kasan_test_c.c | 4 ++++
mm/kasan/shadow.c | 3 ++-
mm/slub.c | 9 +++++++--
scripts/Makefile.lib | 20 +++++++++++---------
11 files changed, 76 insertions(+), 34 deletions(-)
---
base-commit: 038d61fd642278bab63ee8ef722c50d10ab01e8f
change-id: 20250728-kasan-via-kcsan-e5ad0552edbb
--
Jann Horn <jannh@...gle.com>
Powered by blists - more mailing lists