All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Artem Lytkin <iprintercanon@gmail.com>
Cc: Artem Lytkin <iprintercanon@gmail.com>,
	linux-mm@kvack.org, urezki@gmail.com, shivamkalra98@zohomail.in,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/vmalloc: fix 32-bit truncation of the area size in vread_iter()
Date: Sun, 26 Jul 2026 17:25:06 +0200	[thread overview]
Message-ID: <amYm0nL7fn6qsTF2@milan> (raw)
In-Reply-To: <20260725144834.76cd9aa557e72aa02688948f@linux-foundation.org>

On Sat, Jul 25, 2026 at 02:48:34PM -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2026 16:22:00 +0300 Artem Lytkin <iprintercanon@gmail.com> wrote:
> 
> > Commit 0bca23804632 ("mm/vmalloc: use physical page count in
> > vread_iter() for VM_ALLOC areas") replaced get_vm_area_size(vm), which
> > returns a size_t, with vm->nr_pages << PAGE_SHIFT.
> > 
> > struct vm_struct::nr_pages is an unsigned int. The shift operator does
> > not perform the usual arithmetic conversions: the integer promotions are
> > applied to each operand and the type of the result is that of the
> > promoted left operand. The expression is therefore evaluated in 32-bit
> > arithmetic no matter how PAGE_SHIFT is typed, and no matter that the
> > result is assigned to a size_t. Once an area reaches 4 GiB the byte
> > count wraps, at 1 << 20 pages with 4 KiB pages, 1 << 18 with 16 KiB and
> > 1 << 16 with 64 KiB.
> > 
> > ...
> > 
> > Fix it by widening the shift, which also makes the expression consistent
> > with the four (unsigned long)nr_pages << PAGE_SHIFT expressions in
> > vrealloc_node_align_noprof().
> > 
> > On 32-bit a widening cast cannot help, size_t being 32 bits there as
> > well, but a 4 GiB vmalloc area is not reachable on 32-bit either. On
> > 64-bit the cast removes the truncation entirely, which is why replacing
> > get_vm_area_size() introduced a regression rather than inheriting a
> > pre-existing wart.
> > 
> 
> Thanks.  AI review might have found a few things.  Most are
> pre-existing but they are basically "more of the same thing", so you
> may choose to address them?
> 
> 	https://sashiko.dev/#/patchset/20260725132201.88279-1-iprintercanon@gmail.com
> 
> 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.
>
I was thinking about it in same direction. Just to convert and get rid of
casting. It is safe.

--
Uladzislau Rezki


      parent reply	other threads:[~2026-07-26 15:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 13:22 [PATCH 1/2] mm/vmalloc: fix 32-bit truncation of the area size in vread_iter() Artem Lytkin
2026-07-25 21:48 ` Andrew Morton
2026-07-26  9:46   ` Artem Lytkin
2026-07-26 15:25   ` Uladzislau Rezki [this message]

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=amYm0nL7fn6qsTF2@milan \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=iprintercanon@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shivamkalra98@zohomail.in \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.