Thread (32 messages) 32 messages, 5 authors, 2025-08-04

Re: [PATCH v3 01/12] lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option

From: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Date: 2025-07-21 23:19:14
Also in: linux-mm, linux-riscv, linux-s390, linux-um, lkml, loongarch


On 7/18/25 12:10 AM, Andrew Morton wrote:
On Thu, 17 Jul 2025 19:27:21 +0500 Sabyrzhan Tasbolatov [off-list ref] wrote:
quoted
Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
to defer KASAN initialization until shadow memory is properly set up.

Some architectures (like PowerPC with radix MMU) need to set up their
shadow memory mappings before KASAN can be safely enabled, while others
(like s390, x86, arm) can enable KASAN much earlier or even from the
beginning.

This option allows us to:
1. Use static keys only where needed (avoiding overhead)
2. Use compile-time constants for arch that don't need runtime checks
3. Maintain optimal performance for both scenarios

Architectures that need deferred KASAN should select this option.
Architectures that can enable KASAN early will get compile-time
optimizations instead of runtime checks.
Looks nice and appears quite mature.  I'm reluctant to add it to mm.git
during -rc6, especially given the lack of formal review and ack tags.

But but but, that's what the mm-new branch is for.  I guess I'll add it
to get some additional exposure, but whether I'll advance it into
mm-unstable/linux-next for this cycle is unclear.

What do you (and others) think?
After looking a bit, it breaks UM and probably LoongArch too.
I'd say it needs more work and not ready even for mm-new.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help