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

[David Hildenbrand (Arm)]

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?

Does it also cover #8?

-- 
Cheers,

David