Re: [PATCH] filemap: avoid truncating 64-bit offset to 32 bits

Andrew Morton
2025-01-02T22:10:16Z

On Thu, 2 Jan 2025 11:04:11 -0800 Marco Nelissen <marco.nelissen@gmail.com> wrote:

> on 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a
> 64-bit value to 32 bits, leading to a possible infinite loop when writing
> to an xfs filesystem.
>
> ...
>
> +++ b/mm/filemap.c
> @@ -3005,7 +3005,7 @@ static inline loff_t folio_seek_hole_data(struct xa_state *xas,
> if (ops->is_partially_uptodate(folio, offset, bsz) ==
> seek_data)
> break;
> - start = (start + bsz) & ~(bsz - 1);
> + start = (start + bsz) & ~((u64)bsz - 1);
> offset += bsz;
> } while (offset < folio_size(folio));
> unlock:

Thanks. I'll add

Fixes: 54fa39ac2e00b ("iomap: use mapping_seek_hole_data")
Cc: <stable@vger.kernel.org>

The

offset = offset_in_folio(folio, start) & ~(bsz - 1);

a few lines earlier is worrisome. I wonder if we should simply make
`bsz' and `offset' have type u64 and sleep well at night.