Re: TLB free bug in 4c640eb4181c ("mm: move pte table reclaim code to memory.c")

On 8/3/26 10:31, David Hildenbrand (Arm) wrote:
> On 8/1/26 16:00, Andy Lutomirski wrote:
>> Hi all-
>>
>> I saw a fun bug report in ripgrep and a studious but pretty bad
>> AI-generated analysis, and I peeked at the actual code.  I'm rather
>> suspicious of this:
>>
>>     if (can_reclaim_pt) {
>>         if (direct_reclaim || zap_pte_table_if_empty(mm, pmd, start, &pmdval)) {
>>             pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);  <-- what is
>> addr here?
>>             mm_dec_nr_ptes(mm);
>>         }
>>     }
>>
>> It looks to me (and an LLM -- I can *never* remember what all the
>> tlb_xyz functions do, so I asked an LLM for a summary), like addr is
>> not guaranteed to point at the range being zapped, because the do loop
>> above may increment it right past the end.
> 
> It will actually always point at the end, whereby the end is at
> the start of the next page table :/
> 
> pte_table_reclaim_possible() makes sure that we reclaim only when covering a full
> page table.
> 
> Subtracting "PMD_SIZE" from start would ... or just remembering the original start.

Stupid me, we have "start" right there that we can just use.

-- 
Cheers,

David