filemap: avoid truncating 64-bit offset to 32 bits

[marcone]

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.

[marcone]

I have also sent this to upstream, but I don't know if and when it might land there, or which branches it will be included in.
(it is currently here: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/filemap-avoid-truncating-64-bit-offset-to-32-bits.patch)

The problem occurs on 32-bit kernels as far back as 6.1 and all the way through 6.13, and can be reproduced easily using the following shell commands:

hash mkfs.xfs || apt install -y xfsprogs
rm -f xfsimg.bin
truncate -s 6G xfsimg.bin
mkfs.xfs xfsimg.bin
mkdir -p xfs
mount xfsimg.bin xfs
truncate -s 5G xfs/diskimg.bin
mkfs.ext4 xfs/diskimg.bin
mkdir -p mnt
mount xfs/diskimg.bin mnt
dd if=/dev/zero of=mnt/file.bin bs=1M count=4608

On affected kernels, the above will result in a message being printed to the kernel log, after which a kworker thread will be spinning until reboot. On a fixed kernel, the 'dd' command will complete normally.

[popcornmix]

Keep us informed of progress of upstream commit. Once it's accepted we are happy to backport it to older trees.

[pelwell]

If Andrew Morton has signed it off it's as good as merged.

[marcone]

Thanks for merging this. Will this also automatically be included in 6.12.y (which as I understand it will be the next stable kernel Raspberry Pi OS will use)?
And at what point would an image built with pi-gen include this commit?

[pelwell]

The forward port to the newer kernels will happen as a matter of course in the next few days. The pi-gen image is likely to be a significantly longer wait.