Re: [PATCH 08/16] mm/shmem: stop retrying folios that cannot be split

From: Kiryl Shutsemau

Date: Mon Oct 26 2026 - 13:59:51 EST


On Mon, Oct 26, 2026 at 06:08:15PM +0100, David Hildenbrand (Arm) wrote:
> On 10/26/26 17:36, Kiryl Shutsemau wrote:
> > On Mon, Oct 26, 2026 at 10:40:41AM +0100, David Hildenbrand (Arm) wrote:
> >> From: Chris Mason <mason@xxxxxxxxxx>
> >>
> >> A fault or collapse can insert a large folio crossing EOF after
> >> shmem_undo_range() has handled the boundary folios. If splitting that
> >> folio fails, truncate_inode_partial_folio() retains it when it is dirty.
> >> The final scan then repeatedly finds it because it restarts from an
> >> unchanged start.
> >>
> >> Truncation keeps the inode lock and ignores fatal signals while looping.
> >> A concurrent unlink() can then block other directory operations while
> >> holding the directory lock and waiting for the file's lock.
> >>
> >> Advance start past the retained folio, whose truncated part has already
> >> been zeroed. Do not move start backwards if the failed split has shrunk
> >> the folio.
> >>
> >> Fix generated by an LLM and sent by Chris Mason in private.
> >>
> >> Fixes: 55ac8bbe358b ("mm/shmem: fix race in shmem_undo_range w/THP")
> >> Cc: stable@xxxxxxxxxxxxxxx
> >> Signed-off-by: Chris Mason <mason@xxxxxxxxxx>
> >> [ david: split fixes, simplify descriptions, adjust comments ]
> >> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> >
> > Any reason, this should not be in the same patch as 07/16?
> > It is the same failure mode in the same function.
>
> I decided to split because it's a slightly different error mode (failing to
> discard vs. endless loop) and tackles two different commits.

Fair enough.

Acked-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>

--
Kiryl Shutsemau / Kirill A. Shutemov