Re: [External] Re: [PATCH v2 1/3] riscv: mm: Use ASID in update_mmu_cache()

[Xu Lu <luxu.kernel@bytedance.com>]

Thanks, Klara. Thanks, Paul.

Best regards,
Xu Lu

On Sat, Jul 18, 2026 at 1:15 AM Klara Modin <klarasmodin@gmail.com> wrote:
>
> On 2026-07-18 00:57:06 +0800, Xu Lu wrote:
> > Hi Paul,
> >
> > A gentle ping.
> >
> > I have no idea what I can do regarding linux-next. Could you please
> > help revert the patch from version 1 and cherry-pick all the patches
> > from version 2 instead? Or what can I do for this?
>
> Paul has updated the for-next branch at
> git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git so it should
> sort itself out to either today's or monday's next version (depending on
> if the tree has already been pulled or not). Even if it is not pulled
> until monday I think it will be fine, this is what linux-next is for
> after all.
>
> Regards,
> Klara Modin
>
> >
> > Best regards,
> > Xu Lu
> >
> > On Fri, Jul 17, 2026 at 10:11 AM Xu Lu <luxu.kernel@bytedance.com> wrote:
> > >
> > > Hi Paul,
> > >
> > > Klara found that linux-next cherry-picks the new version of patch 2
> > > while picking the old version of patch 1, which leads to an
> > > uninitialized asid. Could you please help correct this?
> > >
> > > Best regards,
> > > Xu Lu
> > >
> > > On Fri, Jul 17, 2026 at 12:25 AM Klara Modin <klarasmodin@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 2026-07-15 21:20:07 +0800, Xu Lu wrote:
> > > > > Only flush TLB entries for the specified mm in update_mmu_cache_range().
> > > > >
> > > > > Signed-off-by: Xu Lu <luxu.kernel@bytedance.com>
> > > > > ---
> > > > >  arch/riscv/include/asm/pgtable.h  | 4 +++-
> > > > >  arch/riscv/include/asm/tlbflush.h | 5 +++++
> > > > >  arch/riscv/mm/tlbflush.c          | 5 -----
> > > > >  3 files changed, 8 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > > > > index 5d5756bda82e..9926556099ae 100644
> > > > > --- a/arch/riscv/include/asm/pgtable.h
> > > > > +++ b/arch/riscv/include/asm/pgtable.h
> > > > > @@ -568,6 +568,8 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
> > > > >               struct vm_area_struct *vma, unsigned long address,
> > > > >               pte_t *ptep, unsigned int nr)
> > > > >  {
> > > > > +     unsigned long asid = get_mm_asid(vma->vm_mm);
> > > > > +
> > > >
> > > > It seems the old version of this patch is still used (at least in
> > > > next-202650716, 15ce1d7c4ddfe0dff00fcaee4ccaeef3efbc62c6), which means
> > > > asid is not initialised here. We instead have:
> > > >
> > > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > > > index 5d5756bda82e..755495a542cc 100644
> > > > --- a/arch/riscv/include/asm/pgtable.h
> > > > +++ b/arch/riscv/include/asm/pgtable.h
> > > > @@ -568,6 +568,8 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
> > > >                 struct vm_area_struct *vma, unsigned long address,
> > > >                 pte_t *ptep, unsigned int nr)
> > > >  {
> > > > +       unsigned long asid;
> > > > +
> > > >         /*
> > > >          * Svvptc guarantees that the new valid pte will be visible within
> > > >          * a bounded timeframe, so when the uarch does not cache invalid
> > > > @@ -583,10 +585,11 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
> > > >          * Relying on flush_tlb_fix_spurious_fault would suffice, but
> > > >          * the extra traps reduce performance.  So, eagerly SFENCE.VMA.
> > > >          */
> > > > +       asid = get_mm_asid(vma->vm_mm);
> > > >         while (nr--)
> > > > -               local_flush_tlb_page(address + nr * PAGE_SIZE);
> > > > -
> > > > +               local_flush_tlb_page_asid(address + nr * PAGE_SIZE, asid);
> > > >  }
> > > > +
> > > >  #define update_mmu_cache(vma, addr, ptep) \
> > > >         update_mmu_cache_range(NULL, vma, addr, ptep, 1)
> > > >
> > > >
> > > > This means that patch 2 of this series will use the uninitialised asid
> > > > for local_svinval_vma() and I get the same behaviour as before (hang on
> > > > initramfs). If I revert the two patches of this series which are in next
> > > > and apply this again it's fine.
> > > >
> > > > Regards,
> > > > Klara Modin
>
> ...