Re: [PATCH v2] mm/filemap: stop fault-around when the walk steps back

["Jose Fernandez (Anthropic)" <jose.fernandez@linux.dev>]

On Thu, 5 Nov 2026 12:19:13 +0000, Pedro Falcato wrote:
> Thank you. So, if I'm not mistaken, this is the race:
> First, you map/see this:
> 	[folio pgoff 4, length 4]
> Then, at some point in time, someone punches the hole:
> 	[no folios here]
> Then, at some point in time, someone faults another folio in the range:
> 	[folio pgoff 0, length 8]
> so you step backwards. Is this correct? Or am I misunderstanding this?

Not quite. In my test a large folio goes away and a small one comes back
below where the walk started. If that happens during the walk's first
lookup, the walk can step back. Krystian's fix doesn't cover that
lookup.

In your order it doesn't step back. The new folio covers the place where
the walk is, so the walk either gets it at the right index or skips its
sibling slots.

> If so, how can this happen while we hold the PTE lock? That itself should
> block truncation.

We don't hold it yet. filemap_map_pages() does the first lookup under
RCU and takes the PTE lock after it.

> Can you share the reproducer?

With the delays it can corrupt memory on a kernel without this patch, so
I'd rather not post it. I can share it off-list with the maintainers if
they want it. The 40 runs without a delay were on a debug kernel with
the delays set to 0.

Andrew, I can send a v3 with this case in the commit message if you
want it.

- Jose