From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC86E2E1722 for ; Sat, 1 Aug 2026 18:52:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785610324; cv=none; b=YTd5ioN4WOVHoVqmjMiQAdwqyPGicwMwLbCXI3h8BWbNwBPZkC+qJ7h06cbYhJnLuy8n/58jh3qSSNbpTZMUNLa23JQvuWWSWFQ5JBB8IwwScFayC8libeaIKsZz4oKG9+7E3XVgq8VPKLk9vk/Xp5oEws9AmN3IuZT3qiEAZHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785610324; c=relaxed/simple; bh=T/jgB+dtcDUyOTZHCieI1u1i/j25o7SmHKQzM4rffMM=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=WiPoMuvCuLvERoASvsXUD2Q1RLMLUaUT9wJbYfL64jSuqU7F2UZnHgBUGHdx0x7JA2SBU0akXIRnCuwvyStiL5x58k1J2wHlb5D3UxF3tEhYr1RHKY9oFeuNKZYq5r98DtivhoYRX5rWfdFXMgplORCwVJkcQ2VBDmtV/uiHRnM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=XzjXVc/j; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="XzjXVc/j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D29F1F00AC4; Sat, 1 Aug 2026 18:52:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785610323; bh=ZiDLjfRmYxoPl7056FsC7JRYJ7y/LJyfmAsEAiZY9Hg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XzjXVc/jwJuVz3QnFD0XjfMzuxZ32xtT3f1TmvjPpVplauz2DYyPcstAkirR2v6Sg xkOsOI3Ffx6oafFKMISTJCPwEMFbCRihB4TPpdcI9MVOUqAGZELrqDjWfnaRBKwAim Wry6QEn8JmSqkoUbL867liGgtaqECq5r/m7zO5A4= Date: Sat, 1 Aug 2026 11:52:02 -0700 From: Andrew Morton To: Artem Lytkin Cc: linux-mm@kvack.org, urezki@gmail.com, willy@infradead.org, shivamkalra98@zohomail.in, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] mm/vmalloc: make vm_struct.nr_pages an unsigned long Message-Id: <20260801115202.ccba41ddac9f7a4f6fb1ca9f@linux-foundation.org> In-Reply-To: <20260801114915.115224-1-iprintercanon@gmail.com> References: <20260730130923.9e71be5f477ee3db333cf0f8@linux-foundation.org> <20260801114915.115224-1-iprintercanon@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 1 Aug 2026 14:49:15 +0300 Artem Lytkin wrote: > vm_struct::nr_pages is an unsigned int, and the file keeps deriving byte > counts from it as nr_pages << PAGE_SHIFT. A shift is evaluated in the type > of its promoted left operand, so those are 32-bit arithmetic and wrap at > 4 GiB of bytes, which is 2^20 pages. Every site depends on a cast being > remembered; vmap() has one, two recent commits did not. vread_iter() then > computes a size of zero for a 4 GiB VM_ALLOC area and /proc/kcore returns > it as zeros while reporting a successful read, which drgn, crash or gdb > cannot tell from real memory, and the vrealloc() grow-in-place check > declines a request that would have fit. > > Widen the field so the class of bug goes away instead of one site at a > time. Everything feeding or consuming it widens too: vm_area_alloc_pages() > and its accumulators, nr_small_pages, new_nr_pages and old_nr_pages, the > index range of vm_area_free_pages(), and three page indexes that were > plain int. Five casts go. Two prints needed fixing as well, %u in > vmalloc_dump_obj() and %d for the unsigned field in vmalloc_info_show(). > > No bug report behind this, I found it reading the code. The 4 GiB wrap > needs only a machine with over 4 GiB of memory. Neither larger threshold > is a practical concern: 2^32 pages, where the field itself truncates, is > 16 TiB and beyond what hardware can populate, and 2^31, where the plain > int indexes break, is 8 TiB and larger than anything in the tree asks for. > The int *nr cursor in the mapping path is unchanged and is separate work. > Users outside mm/vmalloc.c need no change either. Those handing the count > to a narrower parameter cannot drive it near 2^31, and > kho_preserve_vmalloc() stores it into a 32-bit ABI field that still > receives the same low bits; above 2^32 pages the truncation just moves out > of vm_struct into that store. > > sizeof(struct vm_struct) on x86-64 stays 72 bytes with > CONFIG_HAVE_ARCH_HUGE_VMALLOC=n and goes from 72 to 80 with it enabled, > both inside the kmalloc-96 bucket it already comes from. Thanks. Ulad, AI review suggests that vrealloc() has an issue handling __GFP_ZERO. Can you please check? https://sashiko.dev/#/patchset/20260801114915.115224-1-iprintercanon@gmail.com