Re: [PATCH for 6.6 & 6.12] LoongArch: Rework KASAN initialization for PTW-enabled systems

[Huacai Chen]

On Mon, Feb 16, 2026 at 6:20 PM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Feb 16, 2026 at 06:09:31PM +0800, Huacai Chen wrote:
> > Hi, Greg,
> >
> > On Mon, Feb 16, 2026 at 5:52 PM Greg Kroah-Hartman
> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Sun, Feb 15, 2026 at 10:09:53PM +0800, Huacai Chen wrote:
> > > > From: Tiezhu Yang <yangtiezhu@xxxxxxxxxxx>
> > > >
> > > > commit 5ec5ac4ca27e4daa234540ac32f9fc5219377d53 upstream.
> > > >
> > > > "kasan_early_stage = false" indicates that kasan is fully initialized,
> > > > so it should be put at end of kasan_init().
> > > >
> > > > Otherwise bringing up the primary CPU failed when CONFIG_KASAN is set
> > > > on PTW-enabled systems, here are the call chains:
> > > >
> > > >     kernel_entry()
> > > >       start_kernel()
> > > >         setup_arch()
> > > >           kasan_init()
> > > >             kasan_early_stage = false
> > > >
> > > > The reason is PTW-enabled systems have speculative accesses which means
> > > > memory accesses to the shadow memory after kasan_init() may be executed
> > > > by hardware before. However, accessing shadow memory is safe only after
> > > > kasan fully initialized because kasan_init() uses a temporary PGD table
> > > > until we have populated all levels of shadow page tables and writen the
> > > > PGD register. Moving "kasan_early_stage = false" later can defer the
> > > > occasion of kasan_arch_is_ready(), so as to avoid speculative accesses
> > > > on shadow pages.
> > > >
> > > > After moving "kasan_early_stage = false" to the end, kasan_init() can no
> > > > longer call kasan_mem_to_shadow() for shadow address conversion because
> > > > it will always return kasan_early_shadow_page. On the other hand, we
> > > > should keep the current logic of kasan_mem_to_shadow() for both the early
> > > > and final stage because there may be instrumentation before kasan_init().
> > > >
> > > > To solve this, we factor out a new mem_to_shadow() function from current
> > > > kasan_mem_to_shadow() for the shadow address conversion in kasan_init().
> > >
> > > The subject line AND the commit text here do not match the upstream
> > > commit AND the diff is different and you did not explain what changed or
> > > why :(
> > The subject line is exactly the same as the upstream commit (no difference).
> >
> > The changes in the commit message is because the text of the patch has
> > changed (this is why the upstream commit cannot be applied), and I
> > think the commit message should exactly reflect the text.
>
> No, the commit message should match exactly what is merged in Linus's
> tree and then the comments before your new signed-off-by should describe
> what is different here from what is in Linus's tree.  Don't rework
> changelog text for stable backports, that only confuses everyone
> involved and it makes it look like you are doing different things than
> expected (i.e. attempting to get stuff that is NOT upstream merged.)
OK, let me try a V2.

Huacai

>
> thanks,
>
> greg k-h