From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f74.google.com (mail-ed1-f74.google.com [209.85.208.74]) (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 96CAB29A2 for ; Thu, 12 Mar 2026 07:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773302394; cv=none; b=EX2ZU2L5sDRudWUKd/P4vmdWMJ+fO+BEMWv96jC7z1qq4Iqgm14tAjCoY5/SRIDMkgdUvELcrhw9nlI6QPOMygoBRSurkabzyPonyFULSCCj/mxhaDnYpYZiaQqxaLp1vszqNyLj+aiWIgFzVzCULzXoxi8Q1twtxj5Cazoy+xc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773302394; c=relaxed/simple; bh=dcJCiLPilCjX/pzxdDpPmRmIAQOKBr4o/Iun5kqBpDI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HMsQczPOjD8dxHG38bUhbCC0F17sOg5s6LA2tsd2L5ndtS4OVyCmXhU4dNeqzRS8wDf7X8yHdzfb7sCiC4yEu4nC+l0LCC98faFmKQszLQnsHbR4zBsuB54yW4uzInTJuQz6hCR9ojkj05gsV35WBTmDRtcyaU3lWEA9MeCkN/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=l7Mr4Frd; arc=none smtp.client-ip=209.85.208.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="l7Mr4Frd" Received: by mail-ed1-f74.google.com with SMTP id 4fb4d7f45d1cf-663678f9e6bso472830a12.1 for ; Thu, 12 Mar 2026 00:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773302391; x=1773907191; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=veAXwLuzVC+ZNIrlPS+GBtiqKF5VYtsA7fb3KMFtUEM=; b=l7Mr4Frdv4oy+3kVWZO5rSlFP3U9Pb+KLjkcBMevbKCwyydAbVqsVmhqHtwoAXXdn/ TODyjsKfJP6yF2RwYllq8985utVjnme5q6VlUwfC34FzFpwCs0tdH6FjNb21svC2my/o oywnweT9b21Qc8div4vSAg1yKsoydTilZ+ZeBCKj51T44Cpocyebj7VNGB9GS2qf43rx iBwp1Bh9NuZnTUrpbPVuXQKnzP/WfkzLVfFWxG5PRdRsp7V5ZKjIKqezhtjOcdLapp6V 7FzMMjFwSFHmdKfgzm0n3f1VBzX9PRqGgBXxeGZjEMt42fXop4XwDgVZByJY1qziPmYl 8hpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773302391; x=1773907191; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=veAXwLuzVC+ZNIrlPS+GBtiqKF5VYtsA7fb3KMFtUEM=; b=l58EpFHO4Tq4r1FBDiljnzUdFQvSOiY3GYX2M3A8ksipmyaTvo+fexYRZWq00Rr8Yj xBWYKKOimOL2kKCB37IzXFeMxBd7J6xhG20XNTiCXZZYpBl5KoWlykl+ll1FkAFKYjop 8Oxz+ns9os8EHHjSg0rwEAVMirXJDQbifrReNHmJwZf7+hIVMPN5jAWJ3RYq9sa6gpnk fiMKMP1c0RyGbC8LmiSsQ0+xHdphpxycPokkLjIV2Fw/U553vXLxvMR9+yimFMptIcdn mshJl5zKcOA8dpTXibsbSpUx9OYWsZE09Q01q18Bx0epPXSO1AzRUnEsPJBPl2+WMOui 79Wg== X-Forwarded-Encrypted: i=1; AJvYcCUpmkdR/cH38j41ihsZHWdW2yAvJb3DYWWuk/jXKPu8dQmGpEBtGKdtXHloWcBR97ss1ZZrW5cGgz+/c2k=@vger.kernel.org X-Gm-Message-State: AOJu0YxnXdutIqccvEhdEFL4lv7KjmNBkhdDgKQANT6VYr2ZNZzZXU7L WV2E3NRabhhPwNecmYrzqlmLMsSGNK7+ONS8DZey0DESgdLnLF9TXsjatuLfA6QOqntOxN5qV9B 3p2LGDulH93aR4f3WrA== X-Received: from edf9.prod.google.com ([2002:a05:6402:21c9:b0:660:effd:a3f7]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:13d2:b0:662:ac7e:aab9 with SMTP id 4fb4d7f45d1cf-66319cc15a1mr3102004a12.8.1773302390771; Thu, 12 Mar 2026 00:59:50 -0700 (PDT) Date: Thu, 12 Mar 2026 07:59:49 +0000 In-Reply-To: <20260309-vmalloc-shrink-v3-2-5590fd8de2eb@zohomail.in> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260309-vmalloc-shrink-v3-0-5590fd8de2eb@zohomail.in> <20260309-vmalloc-shrink-v3-2-5590fd8de2eb@zohomail.in> Message-ID: Subject: Re: [PATCH v3 2/2] mm/vmalloc: free unused pages on vrealloc() shrink From: Alice Ryhl To: shivamkalra98@zohomail.in Cc: Andrew Morton , Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Danilo Krummrich Content-Type: text/plain; charset="utf-8" On Mon, Mar 09, 2026 at 05:25:46PM +0530, Shivam Kalra via B4 Relay wrote: > From: Shivam Kalra > > When vrealloc() shrinks an allocation and the new size crosses a page > boundary, unmap and free the tail pages that are no longer needed. This > reclaims physical memory that was previously wasted for the lifetime > of the allocation. > > The heuristic is simple: always free when at least one full page becomes > unused. Huge page allocations (page_order > 0) are skipped, as partial > freeing would require splitting. > > The virtual address reservation (vm->size / vmap_area) is intentionally > kept unchanged, preserving the address for potential future grow-in-place > support. > > Fix the grow-in-place check to compare against vm->nr_pages rather than > get_vm_area_size(), since the latter reflects the virtual reservation > which does not shrink. Without this fix, a grow after shrink would > access freed pages. > > Signed-off-by: Shivam Kalra > --- > mm/vmalloc.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 42ae68450a90..114e0bd1030e 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4344,14 +4344,23 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align > goto need_realloc; > } > > - /* > - * TODO: Shrink the vm_area, i.e. unmap and free unused pages. What > - * would be a good heuristic for when to shrink the vm_area? > - */ > if (size <= old_size) { > + unsigned int new_nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT; > + > /* Zero out "freed" memory, potentially for future realloc. */ > if (want_init_on_free() || want_init_on_alloc(flags)) > memset((void *)p + size, 0, old_size - size); > + > + /* Free tail pages when shrink crosses a page boundary. */ > + if (new_nr_pages < vm->nr_pages && !vm_area_page_order(vm)) { > + unsigned long addr = (unsigned long)p; > + > + vunmap_range(addr + (new_nr_pages << PAGE_SHIFT), > + addr + (vm->nr_pages << PAGE_SHIFT)); > + > + vmalloc_free_pages(vm, new_nr_pages, vm->nr_pages); This leaves the range vm->pages[new_nr_pages .. old_nr_pages] with non-NULL but freed page pointers. It seems less error prone to set those entries of vm->pages to NULL here. Note that it's not a problem for existing usage of vmalloc_free_pages(), because it is immediately followed by kvfree(vm->pages). Alice > + vm->nr_pages = new_nr_pages; > + } > vm->requested_size = size; > kasan_vrealloc(p, old_size, size); > return (void *)p; > @@ -4360,7 +4369,7 @@ 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 <= alloced_size) { > + if (size <= (size_t)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 > > -- > 2.43.0 > >