Re: [PATCH 1/2] mm/vmalloc: fix 32-bit truncation of the area size in vread_iter()

[Artem Lytkin]

On Sat, 25 Jul 2026 14:48:34 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> I wonder how much of this stuff would go away if we were to make
> vm_struct.nr_pages an unsigned long?  It's already using 64 bits in the
> CONFIG_HAVE_ARCH_HUGE_VMALLOC=n case.

All the casts, and it's free.

sizeof(struct vm_struct) is 72 today either way. As unsigned long it
stays 72 with HUGE_VMALLOC=n, the 4 byte hole before phys_addr takes it,
and goes to 80 with =y where page_order and nr_pages share a slot. Both
land in kmalloc-96, which is what __get_vm_area_node() allocates from, so
nothing really grows.

That kills both casts here plus the four in vrealloc_node_align_noprof(),
as long as new_nr_pages and old_nr_pages get widened with it. Nothing
outside mm/vmalloc.c needs touching.

It doesn't get all the narrowing though: vm_area_alloc_pages() still
takes and returns unsigned int, nr_small_pages is its own local off size,
"pages=%d" wants %lu, and show_numa_info() uses one unsigned int for both
the page index and the node id.

I'd rather not fold that in here, 1/2 is the kcore regression and the bit
worth backporting. I'll send the widening on top with all of the above in
it.

As for the findings: the vrealloc truncation is 4418, which is 2/2 here,
and there's nothing else narrow left in that function.

nr_small_pages is real but needs more than 16 TiB of RAM, since
__vmalloc_node_range_noprof() checks size >> PAGE_SHIFT against
totalram_pages() first, and I couldn't find a caller allocating that much
in one go. Fixing it alone buys nothing while the other counts are 32
bit, so it goes in the widening patch.

The __GFP_ZERO one I don't think is a bug. The shrink path zeroes when
want_init_on_free() or want_init_on_alloc() is set, and the kerneldoc
already requires callers passing __GFP_ZERO to pass it on every call.

Thanks,
Artem