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

[Paul Walmsley <pjw@kernel.org>]

Hi Vivian,

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().


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv