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

On 8/4/26 15:43, Andy Lutomirski wrote:
> 
>> On Aug 4, 2026, at 2:34 AM, David Hildenbrand (Arm) <[email protected]> wrote:
>>
>> On 8/4/26 11:25, Qi Zheng wrote:
>>>
>>>
>>>
>>> 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.
>>
> 
> If you want a better chance of hitting this bug, you could try:
> 
> - First DONTNEED the range in multiple calls so none of them reclaim the table.

Not required. If MADV_DONTNEED spans the full page table we always reclaim if it
is empty after MADV_DONTNEED (there are some oddities around uffd-wp handling,
which wouldn't apply here).

> 
> - Then PREFETCH the range (or use your favorite speculative read gadget or even do a real read and ignore the signal).  Maybe also do this from multiple CPUs.
> 

Not sure if that's required, but if that's required to trigger it that certainly
makes it less elegant.

> - Trigger reclaim

Also not sure if that one would really help.

> 
> Then do c and d.
> 
> The result might be so specialized that it would be of dubious value.
> 

Right, if we cannot easily trigger it then it's way to special.

-- 
Cheers,

David