[PATCH] riscv: mm: Fix concurrency in mark_new_valid_map()

[Paul Walmsley]

Hi Vivian,

On Thu, 9 Jul 2026, Paul Walmsley wrote:

> On Mon, 29 Jun 2026, Vivian Wang wrote:
> 
> > Turns out, the concurrency concerns [1] were justified - BOSC reported a
> > spurious fault in KFENCE that still triggers despite previous fixes,
> > which KFENCE reports as a false-positive.
> > 
> > Fix the concurrency problems in mark_new_valid_map():
> > 
> > - Add smp_wmb() before filling the bitmap, to make sure page table
> >   writes are "received".
> 
> Probably this expression should be clarified.  I guess the intent here is 
> to ensure that the page table write is visible by other cores either 
> before or simultaneously with the bitmap fill?  And the purpose of that is 
> to avoid a situation where another core could execute an sfence.vma before 
> the PTE write is observable by the other core?  If so, we should probably 
> write something like this out in the commit message.
> 
> I wonder if there's still a window where spurious faults could be observed 
> by kfence.  If another core "B" faults (due to its local TLB caching an 
> invalid PTE) after the PTE write is observable by B, but before the bitmap 
> write is observable by B, core B won't sfence.vma.  If this possibility 
> still exists, we should probably document it.  It might be possible to 
> narrow that window further with a smp_mb() after the bitmap fill, but 
> unclear that it's worth trying unless more spurious faults are seen.
>   
> ...
> 
> Also, now that we're adding an smp_wmb(), we should probably expand the 
> preemption-disabled section in kfence_protect_page() to cover the entire 
> function, to eliminate any risk that the PTE writes execute on a separate 
> CPU from the smp_wmb().

Are you planning to update this one?


- Paul