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

[Zi Yan <ziy@nvidia.com>]

On 26 Oct 2026, at 18:39, Zi Yan wrote:

> 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@kernel.org>
>>>>
>>>> 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@vger.kernel.org
>>>> Signed-off-by: Chris Mason <mason@kernel.org>
>>>> [ david: split fixes, simplify descriptions, adjust comments ]
>>>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>>>> ---
>>>>  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@huaweicloud.com/
>>
>> 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.

To clarify the dependency, without Zhang Yi’s
truncate_inode_partial_folio() patchset, the ext4 + iomap changes
would cause data loss. We probably want to get Zhang Yi’s patches
in first to avoid that.

Patch 7 to 11 do not apply cleanly on top of mm-stable due to Zhang Yi’s
truncate fix, where

1. patch 7 can be dropped as I discussed above,
2. patch 8 needs a folio->mapping guard for the added statement,
3. patch 9-11 can be applied with fuzzy, but I need to look into
them about functionalities before fully trust what LLM says.

The rest of patches have no conflicts on mm-stable.


Best Regards,
Yan, Zi