Re: [PATCH] mm/vmalloc: make vm_struct.nr_pages an unsigned long

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 29 Jul 2026 19:28:36 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Wed, Jul 29, 2026 at 08:57:08PM +0300, Artem Lytkin wrote:
> > A vmalloc area can hold more than 2^32 pages, but the page counts
> 
> I had a "wait, what, really?" moment.  And it can!  2^32 pages is 16TiB,
> and x86-64 says:
> 
>    ffffc90000000000 |  -55    TB | ffffe8ffffffffff |   32 TB | vmalloc/ioremap space (vmalloc_base)
> 
> So we can have _one_ allocation that is more than 2^32 pages.  But I'm
> not sure where we'll get the memory to populate it from.
> https://blogs.oracle.com/cloud-infrastructure/announcing-oci-compute-e6-acceleron-instances
> says I can get 2.3TB of memory in a single machine, which is a factor of
> 8 away from where we'd need to be to actually hit this.
> 
> Intel are adveertising a max memory of 1.5TiB on the 6990E+ (128GiB *
> 12 channels).  So if you put 8 Xeons in a box and loaded it up, that
> could get you to 12TiB.
> 
> I'm not saying we shouldn't fix this, but it's all theoretical for now,
> right?

Artem said "That has produced the same truncation bug twice already,
once in vread_iter() and once in the vrealloc() grow-in-place check". 
This might imply that the issue has been hit in practice, unclear.

Anyway, it's a good change so let's do it.

Sashiko wasn't able to apply it, and the mechanical checking would be
useful here.  I was able to get it to apply, took a bit of work.

So Artem, can you please update the changelog to clarify the above,
redo against mm.git's mm-new branch (or linux-next) and send us a v2?