From: Artem Lytkin <iprintercanon@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, urezki@gmail.com,
shivamkalra98@zohomail.in, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmalloc: make vm_struct.nr_pages an unsigned long
Date: Thu, 30 Jul 2026 12:07:27 +0300 [thread overview]
Message-ID: <20260730090727.65911-1-iprintercanon@gmail.com> (raw)
In-Reply-To: <ampGVI1MLmnLksnN@casper.infradead.org>
On Wed, Jul 29, 2026 at 07:28:36PM +0100, Matthew Wilcox wrote:
> I'm not saying we shouldn't fix this, but it's all theoretical for now,
> right?
The 2^32 page part is, yes, and my opening sentence pointed at the wrong
thing.
What went wrong twice wasn't a page count, it was a byte count. nr_pages
is unsigned int, so nr_pages << PAGE_SHIFT is 32-bit arithmetic and wraps
at 4GiB of bytes, which is 2^20 pages. In vread_iter() that made
/proc/kcore hand back zeros for a 4GiB area as a successful read, and any
machine with more than 4GiB of memory can allocate one. So the reachable
part is 4GiB and the 16TiB framing was me leading with the wrong number.
To answer the other half of it, and Andrew's question too: no report
behind any of this, I found it reading the code. v2 says so in as many
words.
Artem
next prev parent reply other threads:[~2026-07-30 9:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 17:57 [PATCH] mm/vmalloc: make vm_struct.nr_pages an unsigned long Artem Lytkin
2026-07-29 18:28 ` Matthew Wilcox
2026-07-29 21:45 ` Andrew Morton
2026-07-30 9:07 ` Artem Lytkin [this message]
2026-07-30 9:06 ` [PATCH v2 0/3] mm/vmalloc: stop truncating byte counts derived from nr_pages Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 1/3] mm/vmalloc: fix 32-bit truncation of the area size in vread_iter() Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 2/3] mm/vmalloc: fix 32-bit truncation in the vrealloc() grow-in-place check Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 3/3] mm/vmalloc: make vm_struct.nr_pages an unsigned long Artem Lytkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260730090727.65911-1-iprintercanon@gmail.com \
--to=iprintercanon@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivamkalra98@zohomail.in \
--cc=urezki@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox