From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 8634035A3B1 for ; Sun, 26 Jul 2026 09:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785059225; cv=none; b=SdPwTify6i9Cmn5rNnjmp+VYWMQhXOideP1RM9wvIo5ZkL5WLTVNnm1U09g3MuOrj7Xyd7C/qQUIwb6ye4QrXxOpFqFFyfNHBEaRoaFAbh2ZwxyoDdyHmiasDLoreFN3/roh+R2KVcwIO1IMlGQWJQ7GWU4vgqrsk6jpr86LjX4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785059225; c=relaxed/simple; bh=kHul5hcmAB+dPLXbbKhfJTMdbPVNy/vOmCS0QWMAZ2E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=atVLJYHszrwJ0rR2puAFl5IRS0VFBlaxyobE9vkjVnlQxqTYcn6Qo3YGcSB+xElku8GW0PeHAYyzwc6d6Ruw0CUl+xpK8M1+noln5wEeDCt6xqoitdoaKUnuLvpVX5OKaShJ51lZRIIlcIt3Dgn5UaTGue2gwOr8WjfEcF+Mm/g= 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=Nup0tt/m; arc=none smtp.client-ip=209.85.167.48 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="Nup0tt/m" Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5b2aa3be376so1396039e87.0 for ; Sun, 26 Jul 2026 02:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785059221; x=1785664021; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=zGTNSNOhln5X4OCPRtTEj9R34uYX6rw/604aiiTGhzE=; b=Nup0tt/mxjqxdqZLVfg6mhDY3QPEKhW9sQG8g/G44YfUZt+jXg0wYOSWKEbehdU2Qt dFMyFMdcsf9cgDN+VwZ1RyEYuy95Qn8QGm9FjLxt56dNf7YAbUOgOa/+AsunHPQ8+Jdn vqzOSQyKby7ZywRDyzvQ+Jfo5SakMG0GbAqxXuapuYs88i8yvv8prv46ID1Q1zg1bHlW Wg7y5XYopHvgD8PxT8zVMOIcUpqQVUWm/GrX0fACRSZL7yoXuMFvbZihr5rb3uYPBQPk nd3kqPwCIA4BjxYqH0n/C86bBYZwvxf0tcDRcW7Azu6EiQvyOt4qnUvJPKV5shYNZEuR a3Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785059221; x=1785664021; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=zGTNSNOhln5X4OCPRtTEj9R34uYX6rw/604aiiTGhzE=; b=tMWR4BWZoCF2HwV/qGoNICVlj4c2iUDv0ql3HK47c/qhB0QGGbBIYep1M/0VA8n9lh h7OtyRzrbUYG2FbmsWwTkB4JLbWFhozOyhrE4O6nH5Qs4TLDxEGPUsv8fBohj1jdZj+n 38BY7qCqlHj61RmtBNSISoTVVRUWbPgDLjw+xcdN0Ul/5toaWPEMUWNmtL6EXaeNStCe KfOdvzUEbumTyvk66GJcRqgqRZlIHCbxYQpQl5Q+cURThMqbkuLGYXa87iQS4kbe7kDV Wy5Iiic5Ebl0Jg4GoAOyD+gikuuVTYJrlb8ycyyiPlNfuiQVOWYkRyrQ8BU/h15GLknM UqZg== X-Forwarded-Encrypted: i=1; AHgh+Rodl5oiH7tMaLx7Z9mxBXH+UqIDMZu3J9EWf0gCuUgH+1TaTWBybDLpTFcopXeSkq/Fq3fb/ieRrt8tKhU=@vger.kernel.org X-Gm-Message-State: AOJu0YxOko/Pynvmssimu4uveIDYoYFVJD6W1aGxQHK2K1a1CgymM0kf 71/jOxxW0ddszhfYN31z7wwP7hMRIoZspzehn1/Rvvt8YKdoI88Je8sE X-Gm-Gg: AR+sD13A0q4oZW5RKYql0kLdJiybFtZzQT6i4s3V4T1lkkOYKKY88eL1OClsV80rfGX 80qXc8IzYpXlhA3SBa1ZInGbNqQrhnDOH3sjSU4suJ4Fy0jtZUNe8Pzf1AcLFApVpj/+A8Ancg9 rG3nwnkcnpMFwurGpsEbHE0IiMhPByQ8XguX2XBY4EkkweQ9K4jyF0s2ztPu6ryLJOeW4LBu73c d3BPg8HT3jq1uPP5RtCnT1AcVvOeEtSDeud5ewUKdRipgivYUBu1UZ9XzO5ZEtwZ8nNBuxRe7js 0Z2dho+m/jIeVr8YTNVo88xAPpM1MZtrEft+QHjzY6zsl2K+TxBjHiQUZUq8eayzSVpmhGsbHD2 sKxnnmEXug/l7jGebk+ETnpMhB81AgXXo2yeP3UqWEiaocx8mbKlECsVWK8rPgIPFLxOIB695oe rkGdVP9uni7UimQ0LmqyXDI/8cVF6Te4o8jUpLePQcXQ87eaaU6BYZRc24WXpdGu7ibjcQUB9LS BIf X-Received: by 2002:a05:6512:1244:b0:5b2:aa3b:deee with SMTP id 2adb3069b0e04-5b2c1b54a62mr878564e87.35.1785059221326; Sun, 26 Jul 2026 02:47:01 -0700 (PDT) Received: from localhost.localdomain (46-138-176-102.dynamic.spd-mgts.ru. [46.138.176.102]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-39f22236390sm7723271fa.25.2026.07.26.02.47.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jul 2026 02:47:00 -0700 (PDT) From: Artem Lytkin To: Andrew Morton 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() Date: Sun, 26 Jul 2026 12:46:37 +0300 Message-ID: <20260726094637.3210-1-iprintercanon@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260725144834.76cd9aa557e72aa02688948f@linux-foundation.org> 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-Transfer-Encoding: 8bit On Sat, 25 Jul 2026 14:48:34 -0700 Andrew Morton wrote: > 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. All the casts, and it's free. sizeof(struct vm_struct) is 72 today either way. As unsigned long it stays 72 with HUGE_VMALLOC=n, the 4 byte hole before phys_addr takes it, and goes to 80 with =y where page_order and nr_pages share a slot. Both land in kmalloc-96, which is what __get_vm_area_node() allocates from, so nothing really grows. That kills both casts here plus the four in vrealloc_node_align_noprof(), as long as new_nr_pages and old_nr_pages get widened with it. Nothing outside mm/vmalloc.c needs touching. It doesn't get all the narrowing though: vm_area_alloc_pages() still takes and returns unsigned int, nr_small_pages is its own local off size, "pages=%d" wants %lu, and show_numa_info() uses one unsigned int for both the page index and the node id. I'd rather not fold that in here, 1/2 is the kcore regression and the bit worth backporting. I'll send the widening on top with all of the above in it. As for the findings: the vrealloc truncation is 4418, which is 2/2 here, and there's nothing else narrow left in that function. nr_small_pages is real but needs more than 16 TiB of RAM, since __vmalloc_node_range_noprof() checks size >> PAGE_SHIFT against totalram_pages() first, and I couldn't find a caller allocating that much in one go. Fixing it alone buys nothing while the other counts are 32 bit, so it goes in the widening patch. The __GFP_ZERO one I don't think is a bug. The shrink path zeroes when want_init_on_free() or want_init_on_alloc() is set, and the kerneldoc already requires callers passing __GFP_ZERO to pass it on every call. Thanks, Artem