From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 105EA3B8BDA for ; Sun, 2 Aug 2026 15:52:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785685952; cv=none; b=gUjiz6VngG8NwIAxasoB7RUis3ZZMkTqyeTmr4IWQBDxa5d6LHq/G9Di3k7DKcamt8p5GVuP4bEOuwawR4qLAkTTfM30zr1afRQSuGzu3jK4Hi9c7//TatGiTDJFXgeGN7TZnivM1iQMhmCbe2RksjZmCIjXqSqA8pdIP5yfrQg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785685952; c=relaxed/simple; bh=57rRGTEqRzmPh9FhILCRa9vzaobyun3v+0HCmmLIYc8=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=i1ciYzWiOuFtalqeF89iddO+NlE7VIdtffieqrAddcWP2tM/IJZY3uPnE13YRN6uurFRD3R2JQQnm2hdj6shziCjuMx+BeSS3aQXC3ClVg/+L0Jh8RCiW94PEK20m7vaxgXN92VQJMEDcF4dQZrNALzPIxFwt+JxL/NsvH4erWw= 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=HoffSRdW; arc=none smtp.client-ip=209.85.208.44 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="HoffSRdW" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a0de062db5so600750a12.1 for ; Sun, 02 Aug 2026 08:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785685949; x=1786290749; 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=AfsggKPyu3o5by6xB//nU7yz9KE4HCf03TFtDT66V7I=; b=HoffSRdWfYzpse0pPCMOlLT5jng+SxAKEeespehV6mQXxLX4L+6iuUAr6Sm3U66gGT DDNt+d3WLphi88ODSt06u7gZBu5l8mmZECyGiQj3rC//Oq0FbKKtGju/UOhEEN1kLLK2 z4CSb3hc4v5k39ykvoocL+WXIf2fTX4wj4GursvlxuCD0H9HHqdt7tBoYs9qbStpo1Io 5P98HyS1Um4lVQc5FFCYfKkbYJzGODVMRGbBStaU1GpnD+BSJ27LQD6y2JBCvjbu7oCB W/4bGKHo2VCjeiaPpqhD7F5lNOYGTMCWt6yoaR4GnJ7Fymoz7+A/ssl5eLpDYfA9cNqt BfGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785685949; x=1786290749; 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=AfsggKPyu3o5by6xB//nU7yz9KE4HCf03TFtDT66V7I=; b=TxL5ZfB//Blft1hasTQ7CrFUkcs9ypkeN4NKVTsniFFwwVaXd3iwAeAdUqkGVSFsTg eNQm7kJ9r7vOSIAE3Y88HU1u5K+jBvEg47ou2lGxz0oHc0Uye8EIcAlW5Ra3YaAtHDO9 Xwxsi6gN1m/vhSTgaEUSXAyDitPgWda3kjcu2KehOR4ktDW5O3r/znihtdly1q2Z35da Qb5NM9II1mekQVtsAr5fT7J3U3RaC7YdSMVk4dME5HHUShzjt+dXasMVMdB5j40OO3WM HeZ7gDRAbdKT9Jj706Kjh+qBF5DsfEAitJUcE+XA8N5bmEAO/ApsZWLuEpHjEAwQFG/c 3J1g== X-Forwarded-Encrypted: i=1; AHgh+Rr0buQAxm1iY2xwWBwxs1c/7+4GdGbekcdgOFuCeluBW10zNHc+IsmWD5LMPlNFDU2njMfWOfZ2+tz5pj0=@vger.kernel.org X-Gm-Message-State: AOJu0YynXbZZxMYKb6ZnQ+rxn+MLWu8TffQsIuQYUYMNedeH+BlsUnpF ZhYlugLlaIBzanwxcwa3FBYTErMHuyVc7XuZaFLXMharTPVycev7yr6P X-Gm-Gg: AR+sD12Li+SCM4IqxMHiNIAVp0Wb8ufMtqXUxRBZwQaXB7PSQxf4ppGoZz2/ZGtWwDn +KTbBr3Vgu6ZJDhDEo9ImxoppqAgZ/vL+JDQiT1E8e8UbjfLaHMqcnLSxfNMNWrmZYxwpTksIgJ WV80ykQdHjTgE5IXlLifwB64LEcPZjVr2ge/f3kFom/Oc30FLgYRTYbLBEZgqo8I+Z2LFegOLz5 iq0k687Vsc99h95TXsNxUzUq/q+uAMlLIJzB8OUfkIW1ofptoEwKgCUoRhVGLAdlUlFYFUMN9Q+ IHabu/EU6HSrizZY43aYoIB3mM1QCq2Js6UDPX3oAumXOls8k0pMgjzqXFpS7kInB3UfxVXmwiN HM/SDJt/zG5PiOV5Za7it/94RgSwLDI2DWs7fZB32JC7IqVYuMT3DdLY16llZPuDErDYc2RC6lb 3+03NzT2BwOysyDVqI3+k9xCn/3g== X-Received: by 2002:a05:6402:4011:b0:6a0:f9b2:4d67 with SMTP id 4fb4d7f45d1cf-6a0f9b24f94mr154075a12.15.1785685948981; Sun, 02 Aug 2026 08:52:28 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a0d0ed21aesm1101924a12.5.2026.08.02.08.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 08:52:28 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sun, 2 Aug 2026 17:52:26 +0200 To: Andrew Morton Cc: Artem Lytkin , 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: References: <20260730130923.9e71be5f477ee3db333cf0f8@linux-foundation.org> <20260801114915.115224-1-iprintercanon@gmail.com> <20260801115202.ccba41ddac9f7a4f6fb1ca9f@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: <20260801115202.ccba41ddac9f7a4f6fb1ca9f@linux-foundation.org> On Sat, Aug 01, 2026 at 11:52:02AM -0700, Andrew Morton wrote: > 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 > I have checked. I think the AI is missing at least one point. AI argument which is: If a driver initially allocates memory using vmalloc() without __GFP_ZERO (leaving spare page capacity uninitialized), and then grows the allocation using vrealloc() with __GFP_ZERO, the caller expects the newly exposed bytes to be zeroed. In the vrealloc_node_align_noprof() header documentation there is a statement: * If __GFP_ZERO logic is requested, callers must ensure that, starting with the * initial memory allocation, every subsequent call to this API for the same * memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that * __GFP_ZERO is not fully honored by this API. AI argument violates the documentation, i.e. mixing __GFP_ZERO is not allowed. >From the other hand we can mix it and remove that part of documentation: diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 7a0cbba3d29d..28d0fed94d22 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4294,11 +4294,6 @@ EXPORT_SYMBOL(vzalloc_node_noprof); * __GFP_THISNODE flag should be set, otherwise the function will try to avoid * reallocation and possibly disregard the specified @nid. * - * If __GFP_ZERO logic is requested, callers must ensure that, starting with the - * initial memory allocation, every subsequent call to this API for the same - * memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that - * __GFP_ZERO is not fully honored by this API. - * * Requesting an alignment that is bigger than the alignment of the existing * allocation will fail. * @@ -4415,13 +4410,12 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align * We already have the bytes available in the allocation; use them. */ if (size <= vm->nr_pages << PAGE_SHIFT) { - /* - * No need to zero memory here, as unused memory will have - * already been zeroed at initial allocation time or during - * realloc shrink time. - */ - vm->requested_size = size; kasan_vrealloc(p, old_size, size); + + if (want_init_on_alloc(flags)) + memset((void *)p + old_size, 0, size - old_size); + + vm->requested_size = size; return (void *)p; } -- Uladzislau Rezki