Re: [PATCH v4 4/4] mm/truncate: clarify return value of truncate_inode_partial_folio()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: newly split large folios are skipped during shmem truncation
--

commit 15553d4635c639eef475fb728e2da88b1d36fe93
Author: Zhang Yi <yi.zhang@huawei.com>

mm/truncate: clarify return value of truncate_inode_partial_folio()

This commit clarifies the return value of truncate_inode_partial_folio()
to strictly indicate whether at least one split succeeded. The callers now
use this return value as a flag to determine whether the truncation loop
should be reset to pick up newly split sub-folios on the shmem path.

> diff --git a/mm/truncate.c b/mm/truncate.c
> index 81fb4de6226bc..317cb4ae36259 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -216,8 +216,7 @@ static int folio_split_or_unmap(struct folio *folio, struct page *split_at,
>   * aligned inwards to min_order, i.e. the range of folios wholly within
>   * [lstart, lend] and so safe to discard.
>   *
> - * Returns false if splitting failed so the caller can avoid
> - * discarding the entire folio which is stubbornly unsplit.
> + * Return %true if at least one split succeeded, %false otherwise.
>   */
>  bool truncate_inode_partial_folio(struct folio *folio, loff_t lstart,
>  				  loff_t lend, pgoff_t *pstart, pgoff_t *pend)

[Severity: High]
Does shmem_undo_range() still rely on an outdated check instead of just this
return value?

mm/shmem.c:shmem_undo_range() {
    ...
				} else if (truncate_inode_partial_folio(folio,
						lstart, lend, NULL, NULL)) {
					if (!folio_test_large(folio)) {
						folio_unlock(folio);
						index = start;
						break;
					}
				}
    ...
}

Because folio_split() can perform non-uniform splits, the resulting sub-folio
could still be a large folio (order > 0). If it is, folio_test_large(folio)
evaluates to true, so this check prevents the loop from resetting even when
truncate_inode_partial_folio() successfully split it.

Since find_get_entries() has already advanced the search index, the loop
continues from the advanced index and bypasses the newly split sub-folios
within the truncation range.

Can this cause newly split sub-folios to be skipped, leaving them in the page
cache beyond EOF?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922110703.468389-1-yi.zhang@huaweicloud.com?part=4