Re: [PATCH] Fix incorrect flush address in direct page table reclaim

On 8/4/26 11:34, David Hildenbrand (Arm) wrote:
> On 8/4/26 11:25, Qi Zheng wrote:
>>
>>
>> On 8/4/26 5:05 PM, David Hildenbrand (Arm) wrote:
>>>
>>> Note that this only triggers when someone does e.g., a MADV_DONTNEED over
>>> a large enough range (covering at least a full PTE table).
>>>
>>> So this isn't the ordinary munmap()/exit() page table reclaim code.
>>>
>>> I'm still surprised that it took so long to show up; likely we need more
>>> targeted tests for PT_RECLAIM that
>>
>> We backported the PT_RECLAIM to our internal tree a while ago (excluding
>> the rework patch being fixed here), and it has been running stably ever
>> since.
> 
> I'm wondering whether we should have a selftest that triggers this exact scenario:
> 
> (a) Populate page table(s)
> (b) MADV_DONTNEED to reclaim the page table(s)
> (c) Allocate plenty of pages for another purpose (draining PCP where the page
>     table likely ended up) and fill them with some data that looks like present page
>     table entries.
> (d) Re-access the reclaimed VA space, expecting re-population of anonymous
>     pages.

FWIW, I tried to reproduce above and on x86 it's really not able to trigger
easily (as you say, might require some prefetching tricks).

I was able to trigger "something" on arm64, which is just an endless loop
between HW saying "translation exception" and the MM logic saying "looks good
me, continue".

As soon as the walk cache gets flushed (due to some concurrent activity in the
system), the reproducer continues.

-- 
Cheers,

David