Re: [PATCH v4 1/4] mm/truncate: align truncation boundaries to mapping minimum folio order

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] mm: integer overflow in truncate_inode_pages_range causing data loss
--

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

mm/truncate: align truncation boundaries to mapping minimum folio order

This commit aligns the start and end truncation boundaries to the minimum
folio order of the mapping. This prevents valid out-of-range tail sub-folios
from being incorrectly discarded when a mapping has a non-zero min_order.

Link: https://lore.kernel.org/linux-mm/CAJnrk1bQYUe6+1ryyJur5EEnZYrC+_5AYsy=OWzVRgD4202y1g@mail.gmail.com/

> diff --git a/mm/truncate.c b/mm/truncate.c
> index b58ba940be474..f9625bb4916f9 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
[ ... ]
> @@ -374,14 +376,14 @@ void truncate_inode_pages_range(struct address_space *mapping,
[ ... ]
>  	start = (lstart + PAGE_SIZE - 1) >> PAGE_SHIFT;
[ ... ]
>  	else
>  		end = (lend + 1) >> PAGE_SHIFT;
>  
> +	start = round_up(start, min_nrpages);

[Severity: Critical]
Can this integer overflow on 32-bit architectures?

In truncate_inode_pages_range(), pgoff_t is a 32-bit integer on 32-bit
systems. If a hole punch or truncate operation occurs at an offset near
MAX_LFS_FILESIZE, the start page index will be close to 0xFFFFFFFF.

When min_nrpages > 1 (e.g., on filesystems supporting min_order > 0 like
Ext4 with bigalloc), rounding up this index wraps it to 0. 

Would this wrap-around cause the entire page cache for the file to be
truncated instead of just the intended tail, leading to data loss?

> +	if (end != (pgoff_t)-1)
> +		end = round_down(end, min_nrpages);
> +
>  	folio_batch_init(&fbatch);

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