Re: [PATCH v3 7/7] mm/memfd_luo: fix integer overflow in memfd_luo_preserve_folios

[Pratyush Yadav <pratyush@kernel.org>]

On Thu, Mar 26 2026, Chenghao Duan wrote:

> In memfd_luo_preserve_folios(), two variables had types that could cause
> silent data loss with large files:
>
> 1. 'size' was declared as 'long', truncating the 64-bit result of
>    i_size_read(). On 32-bit systems a 4GB file would be truncated to 0,
>    causing the function to return early and discard all data.

As Pasha said, KHO and LUO are not expected to run on 32-bit systems.
Plus, since i_size_read() returns loff_t, why use u64 when you can just
match the type and just use loff_t (which on 64-bit is long anyway)? I
don't get why u64 is any better than long or loff_t.

>
> 2. 'max_folios' was declared as 'unsigned int', causing overflow for
>    sparse files larger than 4TB. For example, a 16TB+4KB file would
>    calculate 0x100000001 folios but truncate to 1 when assigned to
>    max_folios, causing memfd_pin_folios() to pin only the first folio.

Using unsigned int was intentional. We pass max_folios to
memfd_pin_folios(), which expects an unsigned int. So this change is
pointless unless you go and update memfd_pin_folios() too.

I think making memfd_pin_folios() use unsigned long for max_folios makes
a lot of sense, so can you please go update that first before making
this change? And when you do, please match the type of the argument to
the type you use here instead of using u64. This can be a separate,
independent patch series.

>
> Fix by changing both variables to 'u64' to match the types returned
> by i_size_read() and the folio count calculations.
>
> This issue was identified by the AI review.
> https://sashiko.dev/#/patchset/20260323110747.193569-1-duanchenghao@kylinos.cn
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
[...]

-- 
Regards,
Pratyush Yadav