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

[Vivian Wang]

Hi Paul,

On 7/30/26 02:46, Paul Walmsley wrote:
> 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?

Apologies for the delay in response. I think your concerns make sense. I
have been thinking about this and discussing this with BOSC and had not
yet come up with a decisive conclusion. There is also some doubt raised
about what this smp_wmb() is actually fixing. Since this is AFAICT only
possibly known to occur on an internal, RTL-only core, I think it would
be better to come up with a better fix than to slap a random smp_wmb()
in here and calling it a day.

Moreover I will be away until August 10. I recognize that this mean this
patch will miss 7.2, but I think that's better than having, as said, a
random smp_wmb().

Again, apologies,
Vivian "dramforever" Wang