All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>,
	zhengqi.arch@bytedance.com,
	"Liam R . Howlett" <liam.howlett@oracle.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: TLB free bug in 4c640eb4181c ("mm: move pte table reclaim code to memory.c")
Date: Mon, 3 Aug 2026 10:33:09 +0200	[thread overview]
Message-ID: <2504da57-a507-4567-aa5f-bbd3ec17d002@kernel.org> (raw)
In-Reply-To: <f2eb26f4-62e2-4a16-a56b-706adf230cb6@kernel.org>

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


  reply	other threads:[~2026-08-03 13:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01 14:00 TLB free bug in 4c640eb4181c ("mm: move pte table reclaim code to memory.c") Andy Lutomirski
2026-08-03  8:31 ` David Hildenbrand (Arm)
2026-08-03  8:33   ` David Hildenbrand (Arm) [this message]
2026-08-03  9:18   ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2504da57-a507-4567-aa5f-bbd3ec17d002@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=liam.howlett@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=luto@amacapital.net \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=zhengqi.arch@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.