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 490344908D5 for ; Sat, 25 Jul 2026 21:48:35 +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=1785016117; cv=none; b=UvseSn6kuqo1K0dy0oV2q57+qB65Pv2s1GZt7WHqcG6803b6aoWYRWEajR1Pxu281acYTEMot0DTCHZv/+YQ1t2Y9taliIKBDWr7U3l2xdKRBPAxUDMLAdjdgQ7D/XCBOHj8BAxl/GgswPbYxdQfEdYGXNrBPHp3nZzv78B1O7s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785016117; c=relaxed/simple; bh=Hy9ApMskVBVvpUCOEmn1mSfvloFtIKkszbDrFoQodZc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=cy5wimKzsSgCd7lpTG6SydgoSJynOAtpew/ODOUGl1VOhr1Lfy3yDrV1ZHmANAiCz0ePhx6pteZvQmCz+a5LmFnhnScja7pAs02lcQAGwQ1eBxWQRaaZF+uLjFxlEaVz4KQACwlLYtLx7cHsi+xDmSoTnsVL7A3wr297nU69tHI= 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=Q5tlCJp+; 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="Q5tlCJp+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 949C41F000E9; Sat, 25 Jul 2026 21:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785016115; bh=gIBRr+eBTgXMBBErT9R9Qg8c/kYBgNwObuWPPZqXvs8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Q5tlCJp+5kuvY8cf4kWXUs0ywqiXTM00bNoINk9L7CfTK+LqKuTIO70qsQz5IE5hP KEM81/NBfIpRsjhozaJ2js6/6U1rIr9GFGEDrHFPBRa/e8zgZC4F5yGxnVHBaLPnYg yMAEidr703Tt5V+55KBOrapa6Nm+LUS4HcsAzT3U= Date: Sat, 25 Jul 2026 14:48:34 -0700 From: Andrew Morton To: Artem Lytkin Cc: 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() Message-Id: <20260725144834.76cd9aa557e72aa02688948f@linux-foundation.org> In-Reply-To: <20260725132201.88279-1-iprintercanon@gmail.com> References: <20260725132201.88279-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, 25 Jul 2026 16:22:00 +0300 Artem Lytkin 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.