Re: [PATCH 10/10] mm: Use folio_next_pos()

[Matthew Wilcox <willy@infradead.org>]

On Fri, Oct 24, 2025 at 06:08:18PM +0100, Matthew Wilcox (Oracle) wrote:
> +++ b/mm/truncate.c
> @@ -387,7 +387,7 @@ void truncate_inode_pages_range(struct address_space *mapping,
>  	same_folio = (lstart >> PAGE_SHIFT) == (lend >> PAGE_SHIFT);
>  	folio = __filemap_get_folio(mapping, lstart >> PAGE_SHIFT, FGP_LOCK, 0);
>  	if (!IS_ERR(folio)) {
> -		same_folio = lend < folio_pos(folio) + folio_size(folio);
> +		same_folio = lend < folio_next_pos(folio);

This causes an intermittent failure with XFS.  Two reports here:
https://lore.kernel.org/linux-xfs/aQohjfEFmU8lef6M@casper.infradead.org/

This is a fun one.  The "fix" I'm running with right now is:

-               same_folio = lend < folio_next_pos(folio);
+               same_folio = lend < (u64)folio_next_pos(folio);

folio_pos() and folio_next_pos() return an loff_t.  folio_size() returns
a size_t.  So folio_pos() + folio_size() is unsigned (by the usual C
promotion rules).  Before this patch, this was an unsigned comparison
against lend, and with the patch it's now a signed comparison.  Since
lend can be -1 (to mean 'end of file'), same_folio will now be 'true'
when it used to be 'false'.

Funnily, on 32-bit systems, size_t is u32 and loff_t is s64, so their
addition is also s64.  That means this has been wrong on 32-bit systems
for ... a while.  And nobody noticed, so I guess nobody's testing 32-bit
all that hard.

Anyway, what's the *right* way to fix this?  Cast to (unsigned long
long)?  There's an ssize_t, but I really want the opposite, a uloff_t.

(now i'm going to go back through all the other patches in this series
and see if I've made the same mistake anywhere else)