Re: [PATCH] mm: make folio page count functions return unsigned

[David Hildenbrand <david@redhat.com>]

On 27.08.25 03:20, Matthew Wilcox wrote:
> On Tue, Aug 26, 2025 at 06:00:41PM -0400, Aristeu Rozanski wrote:
>> some actually expect an int (e.g. memcg1_charge_statistics()), it'd be a good
>> idea to get those fixed.
> 
> Yes.
> 
>>> Then, e.g., -1 will be (unsigned int)0xffffffff, and casting that to
>>> "long" means trouble, because we wouldn't sign-extend properly and get
>>> (long)0x00000000ffffffff.
>>>
>>> Using "unsigned long" instead work perfectly fine.
>>>
>>> e.g., -1 will be (unsigned long)0xffffffffffffffff. Passing that to a
>>> function that expects "long" or "unsigned long" works as expected.
>>
>> We could run into problems if folio_nr_pages() ever returns an unsigned long
>> larger than LONG_MAX :^)
> 
> I feel comfortable saying that we'll never support a folio size larger
> than 2^31 bytes on 32-bit or 2^63 bytes on 64-bit because folio_size()
> returns a size_t so that constrains us.
Right, otherwise we're back in highmem days where "unsigned long pfn" 
works but "unsigned long long size" is required.

(I hope we'll never have to deal with highmem on 6bit :D ... well, and 
that we can get rid of highmem support on 32bit)

-- 
Cheers

David / dhildenb