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

[Zi Yan]

On 26 Oct 2026, at 17:13, David Hildenbrand (Arm) wrote:

> On 10/26/26 20:21, Zi Yan wrote:
>> 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/
>
> How confident are we that it fixes the same issue?

The issue here is that folio_next_index(folio) used in the mainline
code can be an index lower than lstart and the fix is use max()
to prevent start going backwards. (I wrote this to make sure
I understand the issue correctly)

Zhang Yi’s patch passes start into truncate_inode_parital_folio(),
which has a new signature, and it is updated with the folio’s index
within the [lstart, lend] range at the beginning.

So this patch fixes the issue at the caller and Zhang Yi’s patch
fixes the issue inside truncate_inode_partial_folio().

>
> Does it also cover #8?

No, patch 8 is still needed. I am checking it on how to rebase it
on mm-stable.

Patch 9, 10, 11 might need rebase on mm-stable too.

Since these patches are on top of mainline instead of mm-stable,
you will need to rebase them. IIRC, Zhang Yi’s patches are needed
for ext4 + iomap buffered I/O conversion. Hmm, but Zhang Yi’s
ext4 iomap patches has landed in mainline but its dependency
is not. So we cannot drop Zhang Yi’s patches and ask for a
resend. Adding Zhang Yi here.


Best Regards,
Yan, Zi