Re: [PATCH 11/16] mm/shmem: rescan after nonuniform folio splitting

["Zi Yan" <ziy@nvidia.com>]

On Mon Oct 26, 2026 at 1:26 PM EDT, Kiryl Shutsemau wrote:
> On Mon, Oct 26, 2026 at 10:40:44AM +0100, David Hildenbrand (Arm) wrote:
>> The final scan in shmem_undo_range() restarts after a successful split
>> only if the original folio is no longer large. A nonuniform split can
>> leave that folio large, so the scan skips the newly created folios.
>> Hole punching then leaves pages within the hole allocated even though
>> they could be discarded.
>> 
>> For example, a fault below the hole can allocate a 2 MiB folio after
>> boundary handling. Punching a 1 MiB hole at offset 64 KiB splits the
>> folio successfully but leaves the original folio at order 4. The scan
>> continues past all 512 pages, leaving 2 MiB allocated instead of 1 MiB.
>> The hole reads as zero, but the pages and their block charges remain.
>> 
>> Restart when the original folio is still in the mapping after partial
>> truncation, identified by checking folio->mapping. If the helper
>> removed the whole folio, no rescan is needed.
>> 
>> Fixes: 7460b470a131f ("mm/truncate: use folio_split() in truncate operation")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>
> Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
>
> Do we want split state after truncate_inode_partial_folio() to be
> communicated more explicit? ->mapping check works, but it might not be
> obvious why. Just an idea for a follow up.

Zhang Yi's truncate fix has done that. truncate_inode_partial_folio()
returns true only if the folio is split[1]. His patches are in mm-stable
but not upstreamed yet.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/tree/mm/truncate.c?h=mm-stable#n248

-- 
Best Regards,
Yan, Zi