Re: [PATCH v12 0/5] mm/vmalloc: free unused pages on vrealloc() shrink

Re: [PATCH v12 0/5] mm/vmalloc: free unused pages on vrealloc() shrink

[Shivam Kalra]

On 28/04/26 01:54, Shivam Kalra via B4 Relay wrote:
> This series implements the TODO in vrealloc() to unmap and free unused
> pages when shrinking across a page boundary.
> 
> Problem:
> When vrealloc() shrinks an allocation, it updates bookkeeping
> (requested_size, KASAN shadow) but does not free the underlying physical
> pages. This wastes memory for the lifetime of the allocation.
> 
> Solution:
> - Patch 1: Extracts a vm_area_free_pages(vm, start_idx, end_idx) helper
>    from vfree() that frees a range of pages with memcg and nr_vmalloc_pages
>    accounting. Freed page pointers are set to NULL to prevent stale
>    references.
> - Patch 2: Update the grow-in-place check in vrealloc() to compare the
>    requested size against the actual physical page count (vm->nr_pages)
>    rather than the virtual area sizes. This is a prerequisite for shrinking.
> - Patch 3: Update vread_iter() to derive the vm area size from
>    vm->nr_pages rather than get_vm_area_size(), which would overestimate
>    the mapped range after a shrink.
> - Patch 4: Uses the helper to free tail pages when vrealloc() shrinks
>    across a page boundary.
> - Patch 5: Adds a vrealloc test case to lib/test_vmalloc that exercises
>    grow-realloc, shrink-across-boundary, shrink-within-page, and
>    grow-in-place paths.
> 
> The virtual address reservation is kept intact to preserve the range
> for potential future grow-in-place support.
> A concrete user is the Rust binder driver's KVVec::shrink_to [1], which
> performs explicit vrealloc() shrinks for memory reclamation.
> 
> Tested:
> - KASAN KUnit (vmalloc_oob passes)
> - lib/test_vmalloc stress tests (3/3, 1M iterations each)
> - checkpatch, sparse, W=1, allmodconfig, coccicheck clean
> 
> [1] https://lore.kernel.org/all/20260216-binder-shrink-vec-v3-v6-0-ece8e8593e53@zohomail.in/
> 
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
> Changes in v12:
> - Rewrite vm_area_free_pages() to use free_pages_bulk()
>    following the upstream vfree() refactoring.(Andrew)
> - Drop Reviewed-by tags from Patch 1 due to the rewrite
> - Rebase to latest mm-new
> - Link to v11: https://lore.kernel.org/r/20260420-vmalloc-shrink-v11-0-cad80b00853a@zohomail.in
> 
> Changes in v11:
> - Prepare vread_iter() to use vm->nr_pages instead of
>    get_vm_area_size() (Uladzislau Rezki, Sashiko)
> - Drop (size_t) cast from nr_pages << PAGE_SHIFT (Uladzislau Rezki)
> - Link to v10: https://lore.kernel.org/r/20260404-vmalloc-shrink-v10-0-335759165dfa@zohomail.in
> 
> Changes in v10:
> - Reorder vm->nr_pages to the beginning (Alice Ryhl)
> - Link to v9: https://lore.kernel.org/r/20260401-vmalloc-shrink-v9-0-bf58dfb997d8@zohomail.in
> 
> Changes in v9:
> - Remove READ_ONCE, WRITE_ONCE and drop commit
>    about show_numa_info. (Uladzislau Rezki)
> - Update the commit message in Patch 2. (Alice Ryhl)
> - Remove zero newly exposed memory commit.
> - Link to v8: https://lore.kernel.org/r/20260327-vmalloc-shrink-v8-0-cc6b57059ed7@zohomail.in
> 
> Changes in v8:
> - Strip the KASAN tag from the pointer before addr_to_node()
>    to avoid acquiring the wrong node lock (Sashiko).
> - Rebase to latest mm-new.
> - Link to v7: https://lore.kernel.org/r/20260324-vmalloc-shrink-v7-0-c0e62b8e5d83@zohomail.in
> 
> Changes in v7:
> - Fix NULL pointer dereference in shrink path (Sashiko)
> - Acquire vn->busy.lock when updating vm->nr_pages to synchronize
>    with concurrent readers (Uladzislau Rezki)
> - Use READ_ONCE in vmalloc_dump_obj (Sashiko)
> - Skip shrink path on GFP_NIO or GFP_NOFS. (Sashiko)
> - Fix Overflow issue for large allocations. (Sashiko)
> - Use vrealloc instead of vmalloc in vrealloc test.
> - Link to v6: https://lore.kernel.org/r/20260321-vmalloc-shrink-v6-0-062ca7b7ceb2@zohomail.in
> 
> Changes in v6:
> - Fix VM_USERMAP crash by explicitly bypassing early in the shrink path if the flag is set.(Sashiko)
> - Fix Kmemleak scanner panic by calling kmemleak_free_part() to update tracking on shrink.(Sashiko)
> - Fix /proc/vmallocinfo race condition by protecting vm->nr_pages access with
>    READ_ONCE()/WRITE_ONCE() for concurrent readers.(Sashiko)
> - Fix stale data leak on grow-after-shrink by enforcing mandatory zeroing of the newly exposed memory.(Sashiko)
> - Fix memory leaks in vrealloc_test() by using a temporary pointer to preserve and
>    free the original allocation upon failure.(Sashiko)
> - Rename vmalloc_free_pages parameters from start/end to start_idx/end_idx for better clarity.(Uladzislau Rezki)
> - Link to v5: https://lore.kernel.org/r/20260317-vmalloc-shrink-v5-0-bbfbf54c5265@zohomail.in
> - Link to Sashiko: https://sashiko.dev/#/patchset/20260317-vmalloc-shrink-v5-0-bbfbf54c5265%40zohomail.in
> 
> Changes in v5:
> - Skip vrealloc shrink for VM_FLUSH_RESET_PERMS (Uladzislau Rezki)
> - Link to v4: https://lore.kernel.org/r/20260314-vmalloc-shrink-v4-0-c1e2e0bb5455@zohomail.in
> 
> Changes in v4:
> - Rename vmalloc_free_pages() to vm_area_free_pages() to align with
>    vm_area_alloc_pages() (Uladzislau Rezki)
> - NULL out freed vm->pages[] entries to prevent stale pointers (Alice Ryhl)
> - Remove redundant if (vm->nr_pages) guard in vfree() (Uladzislau Rezki)
> - Add vrealloc test case to lib/test_vmalloc (new patch 3/3)
> - Link to v3: https://lore.kernel.org/r/20260309-vmalloc-shrink-v3-0-5590fd8de2eb@zohomail.in
> 
> Changes in v3:
> - Restore the comment.
> - Rebase to the latest mm-new
> - Link to v2: https://lore.kernel.org/r/20260304-vmalloc-shrink-v2-0-28c291d60100@zohomail.in
> 
> Changes in v2:
> - Updated the base-commit to mm-new
> - Fix conflicts after rebase
> - Ran `clang-format` on the changes made
> - Use a single `kasan_vrealloc` (Alice Ryhl)
> - Link to v1: https://lore.kernel.org/r/20260302-vmalloc-shrink-v1-0-46deff465b7e@zohomail.in
> 
> ---
> Shivam Kalra (5):
>        mm/vmalloc: extract vm_area_free_pages() helper from vfree()
>        mm/vmalloc: use physical page count for vrealloc() grow-in-place check
>        mm/vmalloc: use physical page count in vread_iter()
>        mm/vmalloc: free unused pages on vrealloc() shrink
>        lib/test_vmalloc: add vrealloc test case
> 
>   lib/test_vmalloc.c |  62 +++++++++++++++++++++++++++++++
>   mm/vmalloc.c       | 107 ++++++++++++++++++++++++++++++++++++++++++++++-------
>   2 files changed, 156 insertions(+), 13 deletions(-)
> ---
> base-commit: 4f7b2cc1ad8719d55a8de9675a0aca65cb17c364
> change-id: 20260302-vmalloc-shrink-04b2fa688a14
> 
> Best regards,
Gentle thread bump. Let me know if you have any feedback.

Re: [PATCH v12 4/5] mm/vmalloc: free unused pages on vrealloc() shrink

[Uladzislau Rezki]

On Tue, Apr 28, 2026 at 01:54:19AM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
> 
> 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. Allocations with VM_FLUSH_RESET_PERMS
> are also skipped, as their direct-map permissions must be reset before
> pages are returned to the page allocator, which is handled by
> vm_reset_perms() during vfree().
> 
> Additionally, allocations with VM_USERMAP are skipped because
> remap_vmalloc_range_partial() validates mapping requests against the
> unchanged vm->size; freeing tail pages would cause vmalloc_to_page()
> to return NULL for the unmapped range.
> 
> To protect concurrent readers, the shrink path uses Node lock to
> synchronize before freeing the pages.
> 
> Finally, we notify kmemleak of the reduced allocation size using
> kmemleak_free_part() to prevent the kmemleak scanner from faulting on
> the newly unmapped virtual addresses.
> 
> The virtual address reservation (vm->size / vmap_area) is intentionally
> kept unchanged, preserving the address for potential future grow-in-place
> support.
> 
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
>  mm/vmalloc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 52 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 65e0a23efb3b..9f810d306db9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4346,14 +4346,62 @@ 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.
> +		 *
> +		 * Skip huge page allocations (page_order > 0) as partial
> +		 * freeing would require splitting.
> +		 *
> +		 * Skip VM_FLUSH_RESET_PERMS, as direct-map permissions must
> +		 * be reset before pages are returned to the allocator.
> +		 *
> +		 * Skip VM_USERMAP, as remap_vmalloc_range_partial() validates
> +		 * mapping requests against the unchanged vm->size; freeing
> +		 * tail pages would cause vmalloc_to_page() to return NULL for
> +		 * the unmapped range.
> +		 *
> +		 * Skip if either GFP_NOFS or GFP_NOIO are used.
> +		 * kmemleak_free_part() internally allocates with
> +		 * GFP_KERNEL, which could trigger a recursive deadlock
> +		 * if we are under filesystem or I/O reclaim.
> +		 */
> +		if (new_nr_pages < vm->nr_pages && !vm_area_page_order(vm) &&
> +		    !(vm->flags & (VM_FLUSH_RESET_PERMS | VM_USERMAP)) &&
> +		    gfp_has_io_fs(flags)) {
> +			unsigned long addr = (unsigned long)kasan_reset_tag(p);
> +			unsigned int old_nr_pages = vm->nr_pages;
> +
> +			/*
> +			 * Use the node lock to synchronize with concurrent
> +			 * readers (vmalloc_info_show).
> +			 */
> +			struct vmap_node *vn = addr_to_node(addr);
> +
> +			spin_lock(&vn->busy.lock);
> +			vm->nr_pages = new_nr_pages;
> +			spin_unlock(&vn->busy.lock);
> +
> +			/* Notify kmemleak of the reduced allocation size before unmapping. */
> +			kmemleak_free_part(
> +				(void *)addr + ((unsigned long)new_nr_pages
> +						<< PAGE_SHIFT),
> +				(unsigned long)(old_nr_pages - new_nr_pages)
> +					<< PAGE_SHIFT);
> +
> +			vunmap_range(addr + ((unsigned long)new_nr_pages
> +					     << PAGE_SHIFT),
> +				     addr + ((unsigned long)old_nr_pages
> +					     << PAGE_SHIFT));
> +
> +			vm_area_free_pages(vm, new_nr_pages, old_nr_pages);
> +		}
>  		vm->requested_size = size;
>  		kasan_vrealloc(p, old_size, size);
>  		return (void *)p;
> 
> -- 
> 2.43.0
> 
> 
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki

Re: [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()

[Uladzislau Rezki]

On Tue, Apr 28, 2026 at 01:54:18AM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
> 
> Update vread_iter() to derive the vm area size from vm->nr_pages rather
> than get_vm_area_size().
> 
> Currently both values are equivalent, but the upcoming vrealloc() shrink
> functionality will free pages without reducing the virtual reservation
> size. After such a shrink, the old get_vm_area_size() based calculation
> would overestimate the mapped range, causing vread_iter() to attempt
> reading from unmapped addresses. Switch to vm->nr_pages now so the
> reader remains correct once shrink support is added.
> 
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
>  mm/vmalloc.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 9cb3e287a1e8..65e0a23efb3b 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4661,7 +4661,14 @@ long vread_iter(struct iov_iter *iter, const char *addr, size_t count)
>  		smp_rmb();
>  
>  		vaddr = (char *) va->va_start;
> -		size = vm ? get_vm_area_size(vm) : va_size(va);
> +		if (vm)
> +			/*
> +			 * Cannot use get_vm_area_size() because realloc()
> +			 * may shrink the mapping and area->size may be outdated.
> +			 */
> +			size = vm->nr_pages << PAGE_SHIFT;
> +		else
> +			size = va_size(va);
>  
>  		if (addr >= vaddr + size)
>  			goto next_va;
> 
> -- 
> 2.43.0
> 
> 
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki

Re: [PATCH v12 1/5] mm/vmalloc: extract vm_area_free_pages() helper from vfree()

[Uladzislau Rezki]

On Tue, Apr 28, 2026 at 01:54:16AM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
> 
> Extract page freeing and NR_VMALLOC stat accounting from
> vfree() into a reusable vm_area_free_pages() helper.
> The helper operates on a range [start_idx, end_idx) of pages
> from a vm_struct, making it suitable for both full free (vfree)
> and partial free (upcoming vrealloc shrink).
> 
> Freed page pointers in vm->pages[] are set to NULL
> to prevent stale references when the vm_struct outlives the
> free (as in vrealloc shrink).
> 
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
>  mm/vmalloc.c | 34 +++++++++++++++++++++++++++-------
>  1 file changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 878c5b7bf837..1073abb6094e 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3416,6 +3416,32 @@ void vfree_atomic(const void *addr)
>  		schedule_work(&p->wq);
>  }
>  
> +/*
> + * vm_area_free_pages - free a range of pages from a vmalloc allocation
> + * @vm: the vm_struct containing the pages
> + * @start_idx: first page index to free (inclusive)
> + * @end_idx: last page index to free (exclusive)
> + *
> + * Free pages [start_idx, end_idx) updating NR_VMALLOC stat accounting.
> + * Freed vm->pages[] entries are set to NULL.
> + * Caller is responsible for unmapping (vunmap_range) and KASAN
> + * poisoning before calling this.
> + */
> +static void vm_area_free_pages(struct vm_struct *vm, unsigned int start_idx,
> +			       unsigned int end_idx)
> +{
> +	unsigned int i;
> +
> +	if (!(vm->flags & VM_MAP_PUT_PAGES)) {
> +		for (i = start_idx; i < end_idx; i++)
> +			mod_lruvec_page_state(vm->pages[i], NR_VMALLOC, -1);
> +	}
> +	free_pages_bulk(vm->pages + start_idx, end_idx - start_idx);
> +
> +	for (i = start_idx; i < end_idx; i++)
> +		vm->pages[i] = NULL;
> +}
> +
>  /**
>   * vfree - Release memory allocated by vmalloc()
>   * @addr:  Memory base address
> @@ -3436,7 +3462,6 @@ void vfree_atomic(const void *addr)
>  void vfree(const void *addr)
>  {
>  	struct vm_struct *vm;
> -	int i;
>  
>  	if (unlikely(in_interrupt())) {
>  		vfree_atomic(addr);
> @@ -3460,12 +3485,7 @@ void vfree(const void *addr)
>  	if (unlikely(vm->flags & VM_FLUSH_RESET_PERMS))
>  		vm_reset_perms(vm);
>  
> -	if (!(vm->flags & VM_MAP_PUT_PAGES)) {
> -		for (i = 0; i < vm->nr_pages; i++)
> -			mod_lruvec_page_state(vm->pages[i], NR_VMALLOC, -1);
> -	}
> -	free_pages_bulk(vm->pages, vm->nr_pages);
> -
> +	vm_area_free_pages(vm, 0, vm->nr_pages);
>  	kvfree(vm->pages);
>  	kfree(vm);
>  }
> 
> -- 
> 2.43.0
> 
> 
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki

Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Uladzislau Rezki]

On Tue, Apr 28, 2026 at 01:54:17AM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
> 
> Update the grow-in-place check in vrealloc() to compare the requested size
> against the actual physical page count (vm->nr_pages) rather than the
> virtual area size (alloced_size, derived from get_vm_area_size()).
> 
> Currently both values are equivalent, but the upcoming vrealloc() shrink
> functionality will free pages without reducing the virtual reservation
> size. After such a shrink, the old alloced_size-based comparison would
> incorrectly allow a grow-in-place operation to succeed and attempt to
> access freed pages. Switch to vm->nr_pages now so the check remains
> correct once shrink support is added.
> 
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
>  mm/vmalloc.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 1073abb6094e..9cb3e287a1e8 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4338,6 +4338,12 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
>  		if (unlikely(flags & __GFP_THISNODE) && nid != NUMA_NO_NODE &&
>  			     nid != page_to_nid(vmalloc_to_page(p)))
>  			goto need_realloc;
> +	} else {
> +		/*
> +		 * If p is NULL, vrealloc behaves exactly like vmalloc.
> +		 * Skip the shrink and in-place grow paths.
> +		 */
> +		goto need_realloc;
>  	}
>  
>  	/*
> @@ -4356,7 +4362,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 <= vm->nr_pages << PAGE_SHIFT) {
>  		/*
>
Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
In that case, we do not need to switch to vm->nr_pages? And we do not
need 

[PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()

?

--
Uladzislau Rezki

Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Shivam Kalra]

On 07/05/26 00:17, Uladzislau Rezki wrote:
> Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
> In that case, we do not need to switch to vm->nr_pages? And we do not
> need
> 
> [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()
> 
> ?
> 
> --
> Uladzislau Rezki
I didn't want to change the va in this patch series and wanted to keep
it simple.
If we change the va, we will also need to rebalance the rb tree.
I can work on a followup patch series if VA space pressure is critical.

Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Uladzislau Rezki]

On Thu, May 07, 2026 at 01:13:35AM +0530, Shivam Kalra wrote:
> On 07/05/26 00:17, Uladzislau Rezki wrote:
> > Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
> > In that case, we do not need to switch to vm->nr_pages? And we do not
> > need
> > 
> > [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()
> > 
> > ?
> > 
> > --
> > Uladzislau Rezki
> I didn't want to change the va in this patch series and wanted to keep
> it simple.
> If we change the va, we will also need to rebalance the rb tree.
> I can work on a followup patch series if VA space pressure is critical.
>
Actually it is not critical. The idea is if we shrink VA then we do not
need care much about the size thus keeping vread_iter() unchanged as
well as [PATCH v12 2/5]? at least partly.

I am find with it anyway.

Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki

Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Shivam Kalra]

On 07/05/26 22:51, Uladzislau Rezki wrote:
> On Thu, May 07, 2026 at 01:13:35AM +0530, Shivam Kalra wrote:
>> On 07/05/26 00:17, Uladzislau Rezki wrote:
>>> Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
>>> In that case, we do not need to switch to vm->nr_pages? And we do not
>>> need
>>>
>>> [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()
>>>
>>> ?
>>>
>>> --
>>> Uladzislau Rezki
>> I didn't want to change the va in this patch series and wanted to keep
>> it simple.
>> If we change the va, we will also need to rebalance the rb tree.
>> I can work on a followup patch series if VA space pressure is critical.
>>
> Actually it is not critical. The idea is if we shrink VA then we do not
> need care much about the size thus keeping vread_iter() unchanged as
> well as [PATCH v12 2/5]? at least partly.
> 
> I am find with it anyway.
> 
> Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> 
> --
> Uladzislau Rezki

Thanks for the review.

There's actually one more benefit of this approach for a future
grow-in-place optimization: since the VA reservation is kept intact
after a shrink, a subsequent grow wouldn't need to allocate a new
virtual address range or manipulate the vmap_area tree. It could
allocate and map new pages directly into the existing VA range.
So for workloads where shrinking and growing occur frequently,
this approach lays better groundwork.

Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Uladzislau Rezki]

On Fri, May 08, 2026 at 12:36:18AM +0530, Shivam Kalra wrote:
> On 07/05/26 22:51, Uladzislau Rezki wrote:
> > On Thu, May 07, 2026 at 01:13:35AM +0530, Shivam Kalra wrote:
> > > On 07/05/26 00:17, Uladzislau Rezki wrote:
> > > > Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
> > > > In that case, we do not need to switch to vm->nr_pages? And we do not
> > > > need
> > > > 
> > > > [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()
> > > > 
> > > > ?
> > > > 
> > > > --
> > > > Uladzislau Rezki
> > > I didn't want to change the va in this patch series and wanted to keep
> > > it simple.
> > > If we change the va, we will also need to rebalance the rb tree.
> > > I can work on a followup patch series if VA space pressure is critical.
> > > 
> > Actually it is not critical. The idea is if we shrink VA then we do not
> > need care much about the size thus keeping vread_iter() unchanged as
> > well as [PATCH v12 2/5]? at least partly.
> > 
> > I am find with it anyway.
> > 
> > Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > 
> > --
> > Uladzislau Rezki
> 
> Thanks for the review.
> 
> There's actually one more benefit of this approach for a future
> grow-in-place optimization: since the VA reservation is kept intact
> after a shrink, a subsequent grow wouldn't need to allocate a new
> virtual address range or manipulate the vmap_area tree. It could
> allocate and map new pages directly into the existing VA range.
> So for workloads where shrinking and growing occur frequently,
> this approach lays better groundwork.
>
Fair point, so there are pros and cons.

--
Uladzislau Rezki

Re: [PATCH v12 0/5] mm/vmalloc: free unused pages on vrealloc() shrink

[Andrew Morton]

On Tue, 5 May 2026 21:12:15 +0530 Shivam Kalra <shivamkalra98@zohomail.in> wrote:

> > base-commit: 4f7b2cc1ad8719d55a8de9675a0aca65cb17c364
> > change-id: 20260302-vmalloc-shrink-04b2fa688a14
> > 
> > Best regards,
> Gentle thread bump. Let me know if you have any feedback.

It's been a while - I suggest a resend.

For some reason AI review couldn't apply v12
(https://sashiko.dev/#/patchset/20260428-vmalloc-shrink-v12-0-3c18c9172eb1@zohomail.in)
- perhaps it'll work next time.