[PATCH v2 01/11] kasan: unify static kasan_flag_enabled across modes

Heiko Carstens hca at linux.ibm.com
Tue Jul 1 00:39:34 AEST 2025


On Mon, Jun 30, 2025 at 02:31:00PM +0200, Alexander Gordeev wrote:
> On Thu, Jun 26, 2025 at 08:31:37PM +0500, Sabyrzhan Tasbolatov wrote:
> 
> Hi Sabyrzhan,
> 
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index d54e89f8c3e..32c432df24a 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -36,6 +36,17 @@
> >  #include "kasan.h"
> >  #include "../slab.h"
> >  
> > +/*
> > + * Initialize Generic KASAN and enable runtime checks.
> > + * This should be called from arch kasan_init() once shadow memory is ready.
> > + */
> > +void __init kasan_init_generic(void)
> > +{
> > +	static_branch_enable(&kasan_flag_enabled);
> 
> s390 crashes at this line, when the whole series is applied.
> 
> FWIW, it looks like kasan is called while its state is not yet finalized.
> E.g. whether calling __asan_report_store4_noabort() before kasan_init_generic()
> is expected?

It crashes because with this conversion a call to static_branch_enable() is
introduced. This one get's called way before jump_label_init() init has been
called. Therefore the STATIC_KEY_CHECK_USE() in static_key_enable_cpuslocked()
triggers.

This again tries to emit a warning. Due to lack of console support that early
the kernel crashes.

One possible solution would be to move the kasan init function to
arch/s390/kernel/setup.c, after jump_label_init() has been called.
If we want this, is a different question.

It seems to work, so I see no reason for not doing that.

Vasily, since you did nearly all of the KASAN work for s390, do you have any
opinion about this?


More information about the Linuxppc-dev mailing list