Re: [PATCH 07/16] mm/shmem: avoid moving the truncation start backwards

[Zi Yan]

On 26 Oct 2026, at 5:40, David Hildenbrand (Arm) wrote:

> From: Chris Mason <mason@xxxxxxxxxx>
>
> A nonuniform folio split can fail with -ENOMEM after splitting off some
> smaller folios. shmem_undo_range() then sets start to the end of the
> original folio, which may now lie before the truncation boundary.
>
> The final scan can consequently discard data below the new EOF, or
> keep retrying a large folio whose split point lies outside it.
>
> Keep start at least at its original value when skipping a folio after
> a failed split. The part in the truncated range has already been zeroed.
>
> Fix generated by an LLM and sent by Chris Mason in private.
>
> Fixes: 7460b470a131f ("mm/truncate: use folio_split() in truncate operation")
> 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>
> ---
>  mm/shmem.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>

This is fixed by Zhang Yi’s truncate_inode_partial_folio() fix[1].
I think the commit is ad27479793682 ("mm/truncate: fix data loss
when splitting straddling large folios fails") in mm-stable but
not upstream yet.

[1] https://lore.kernel.org/all/20260928120833.3440834-4-yi.zhang@xxxxxxxxxxxxxxx/

Best Regards,
Yan, Zi