All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhang Yi" <yi.zhang@huaweicloud.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH v3 3/3] mm/truncate: clarify return value of truncate_inode_partial_folio()
Date: Wed, 16 Sep 2026 09:45:11 +0000	[thread overview]
Message-ID: <20260916094511.9B42F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916092450.654408-4-yi.zhang@huaweicloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: sub-folio page cache leak due to incorrect end boundary on split failure
--

commit 4bfa9d8fcd26bcd7a9625b0b4e4d07b1e0a6b145
Author: Zhang Yi <yi.zhang@huawei.com>

mm/truncate: clarify return value of truncate_inode_partial_folio()

This commit updates truncate_inode_partial_folio() to clarify its return
value semantics. Callers now use the return value strictly as a flag for
loop resetting, and rely instead on the pstart and pend out-parameters
to decide whether to adjust the truncation range.

> diff --git a/mm/truncate.c b/mm/truncate.c
> index 5ab7a40b1e256..23c90f00b5300 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
[ ... ]
> @@ -331,10 +330,9 @@ bool truncate_inode_partial_folio(struct folio *folio, loff_t lstart,
>  			*pend = end;
>  		return true;
>  	}

[Severity: High]
With the new caller dependency on pstart and pend instead of the return
value, can this error path cause a sub-folio page cache leak?

If truncate_inode_partial_folio() is called for a range within a single
large folio, and the first split succeeds, *pstart is advanced. If the
second split attempt fails early during folio2 validation, the code behaves
as follows:

mm/truncate.c:truncate_inode_partial_folio() {
    ...
    end = folio->index;
    if (!folio_try_get(folio2))
        goto out;
    ...
out:
    if (pend)
        *pend = end;
    return true;
}

Does this set *pend backward to the start of the original large folio?

If this results in a situation where *pstart is greater than *pend, will
the caller bypass its discard loop entirely? This seems like it could
permanently leak all successfully split sub-folios in the range within the
page cache. For hole punches, could this result in reading stale data
instead of zeros?

> -	if (folio_test_dirty(folio))
> -		return false;
> -	truncate_inode_folio(folio->mapping, folio);
> -	return true;
> +	if (!folio_test_dirty(folio))
> +		truncate_inode_folio(folio->mapping, folio);
> +	return false;
>  }
>  
>  /*

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

      reply	other threads:[~2026-09-16  9:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  9:24 [PATCH v3 0/3] mm/truncate: fix data loss when truncating straddling large folios Zhang Yi
2026-09-16  9:24 ` [PATCH v3 1/3] mm/truncate: fix data loss when splitting straddling large folios fails Zhang Yi
2026-09-16  9:45   ` sashiko-bot
2026-09-16 12:02   ` Jan Kara
2026-09-16 18:03     ` Zi Yan
2026-09-17 11:38       ` Zhang Yi
2026-09-17 12:03         ` Zhang Yi
2026-09-21  9:05           ` Jan Kara
2026-09-22  1:11             ` Zhang Yi
2026-09-16 17:38   ` Brian Foster
2026-09-17 11:48     ` Zhang Yi
2026-09-16  9:24 ` [PATCH v3 2/3] mm/truncate: align truncation boundaries to mapping minimum folio order Zhang Yi
2026-09-16  9:42   ` sashiko-bot
2026-09-16 21:14   ` Zi Yan
2026-09-17 12:32     ` Zhang Yi
2026-09-16  9:24 ` [PATCH v3 3/3] mm/truncate: clarify return value of truncate_inode_partial_folio() Zhang Yi
2026-09-16  9:45   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260916094511.9B42F1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.