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

> On Aug 4, 2026, at 2:34=E2=80=AFAM, David Hildenbrand (Arm) <david@kernel.=
org> wrote:
>=20
> =EF=BB=BFOn 8/4/26 11:25, Qi Zheng wrote:
>>=20
>>=20
>>> On 8/4/26 5:05 PM, David Hildenbrand (Arm) wrote:
>>> On 8/4/26 02:37, [email protected] wrote:
>>>> From: Andy Lutomirski <[email protected]>
>>>>=20
>>>> When zap_pte_range reclaims a page table, it does:
>>>>=20
>>>>      pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
>>>>=20
>>>> and this is unconditionally wrong: if this code executes, addr *always*=

>>>> points one past the end of the range covered by the table.  The addr
>>>> parameter is used to flush the TLB (really the paging-structure-cache)
>>>> to drop references to the to-be-freed table, and any architecture that
>>>> cares about the parameter will flush the wrong address.  (But they'll
>>>> still free the correct page).
>>>>=20
>>>> I think it's worth contemplating why the kernel works at all.
>>>=20
>>> Note that this only triggers when someone does e.g., a MADV_DONTNEED ove=
r
>>> a large enough range (covering at least a full PTE table).
>>>=20
>>> So this isn't the ordinary munmap()/exit() page table reclaim code.
>>>=20
>>> I'm still surprised that it took so long to show up; likely we need more=

>>> targeted tests for PT_RECLAIM that
>>=20
>> 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.
>=20
> I'm wondering whether we should have a selftest that triggers this exact s=
cenario:
>=20
> (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 p=
age
>    table likely ended up) and fill them with some data that looks like pre=
sent page
>    table entries.
> (d) Re-access the reclaimed VA space, expecting re-population of anonymous=

>    pages.
>=20

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 tab=
le.

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

- Trigger reclaim

Then do c and d.

The result might be so specialized that it would be of dubious value.

> I can find someone to work on that.
>=20
> Any other ideas what we could check? We could certainly also check that th=
e page table
> was actually reclaimed during MADV_DONTNEED.
>=20
> --
> Cheers,
>=20
> David