From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A79C21B4F0A for ; Sun, 26 Jul 2026 15:25:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785079512; cv=none; b=kxitEhbga+njK0wSFz2LzfHi8v+5zQbhD+HfdifCs+uG6YyIo9p1fZ1k7UJWKTaVnD+NZO7uh08Fav0gel8BtVVwyOWBRXVxILs8G676jIArE9/Z4tsfgP7EyeE1Nho1TnhnTdDxn1mCN0VkWlPZqQCWUQfmsZlYCWfrjFjjiME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785079512; c=relaxed/simple; bh=ykClGxUhfH39cpmxszKwfwl43Kcn3GemTjr/nwq7yYE=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hndsdaRcFQylHsmyoT49/AUXOQBtuntebXtoTPBv9dmk7py2JyxewMF5WOZ1kjURN4dANRb29yrc46gQ8vXRa9Bh3vIJbkOu2lOogj3fzkGbV9oZW8rdX98CWnjvc9DxqNM5ZXreSVFH2cyRW3/Mz/1NwgmEXgayLbhmdVOBhPg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UsxpcieT; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UsxpcieT" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c15dd4b9132so289647166b.1 for ; Sun, 26 Jul 2026 08:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785079509; x=1785684309; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=hrZzytWG33HIkttwtiI0GBdDtPqgitxwYOUNbEboLhQ=; b=UsxpcieTNrUm2DsjGfaD0ef/9gSc5CY57C/qLyEb4SB5duTsQiB8HW9dox3r7X3yOB 5SZzbP3jgdDs7NB/tPcjCK5gCATVJSzx0gQa/fke+Fsj/EyPgv4Yr97eQbOFdLfUeV+N 5I1PQ2lHY6tCo75KqrcH8SgdjED3me64FPqQscyeXsHhq7WdPejpnVQd4bOR/bKXcHWW 5BULN0ofV2ionXndQjXhPPotBtfnvK10KJ4rBSZitE2WZ//a/agyQSpBxrLQqNJWcQMq a7k3UKk4K6V+QCpT0shSCzKzqJgkOVEHnrPOUQR2363/rkbFbiW42neTr4XvEgYrRP2m 0lqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785079509; x=1785684309; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hrZzytWG33HIkttwtiI0GBdDtPqgitxwYOUNbEboLhQ=; b=RIfHbSCczpUwO+rbdm02aDci3geUw55WKbPqf0aTEIeHtpFr7W/oFoJXvEmy6REOOB QTlFS3lKhJa22s8EfiZokz+iMG+RIk8hI4MkFVUgtIItbRAYTa4FJEyOUCI+TgyjXHON RowmHbmxa3t7Elr2dQAUAO7kPzKJjOTf4Nigh3frcmy50c9Z5L0/F27XHmTLWFsjWeXe Du8jVQfdCbgulEk5IvSQTOEdsbbOypg2/M9tlQbKnC5majVhA4dquYFSjASyyx2LTR4P mifMdqQ83cwmClojM+6zM11J9pu+JeUg2EEMyGd6pZ7+o7/aNYoXxvmj6+mHKuEaZFj7 mW8Q== X-Forwarded-Encrypted: i=1; AHgh+RrKeKURNYv8XyCED2zHLEuyKxgJZ/eDBhTPsxxb1sEiY3g9hV8aUYnBLBCfRk2d/rXjf5Qe1s6br+bSMbg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx3ubD+HGIxlYwk+lZkriTgkpA6KGkbBzZLOMLk0WckQ2EPY6dW HlPR+1GELF23XZDa46Cq6LpJb7AAeF4xksSAZvFrKrmTkdcUId4CDIl/ X-Gm-Gg: AR+sD12W8rxk+bTP01KUNVbKYCQmJwKI+2WkqBqI7RLdQDpJQn31eWLDBEKkKmZspKv nmXpfvgUHw9jXnyrgS7vHdDm53f604W4E4xZ8DZSfUspPyzZDb7GQiJ2WIdFiaz0cIQVEnILtZ5 R8vyLTyI4xNLwp0D4S5odB4Da8V0T2xY6Ucj8ZG4kFzVDxc5Pr9LDkKlB///xqbeBVR8lVpkmiW IahiCx/2NkwgZNWmNs9kbPjn6o1HdRTNmVCdHI0lBY5ihomxAh+ssvUpEpiWHpbgsFHpuqNcaaI zL3LRPjYwyp6FrQEMghop7qEwFUJBU9UecAHNsqxrY6GR6yPPcUppEIz9ek1d/FKrz7ObdrBnPk BRjUcg+zXt55H4RtuEyrAnSFZAODfMEZFVflsXawoMB4= X-Received: by 2002:a17:906:794a:b0:c15:c1ad:36dd with SMTP id a640c23a62f3a-c1f1eabbad5mr214982866b.6.1785079508823; Sun, 26 Jul 2026 08:25:08 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1c32ac936dsm559433666b.22.2026.07.26.08.25.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jul 2026 08:25:08 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sun, 26 Jul 2026 17:25:06 +0200 To: Andrew Morton , Artem Lytkin Cc: Artem Lytkin , 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: References: <20260725132201.88279-1-iprintercanon@gmail.com> <20260725144834.76cd9aa557e72aa02688948f@linux-foundation.org> 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-Disposition: inline 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 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