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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@linuxfoundation.org> wrote:
> >
> > On Sun, Feb 15, 2026 at 10:09:53PM +0800, Huacai Chen wrote:
> > > From: Tiezhu Yang <yangtiezhu@loongson.cn>
> > >
> > > 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.)

thanks,

greg k-h