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

[Shivam Kalra <shivamkalra98@zohomail.in>]

On 03/03/26 14:40, Alice Ryhl wrote:
> On Mon, Mar 2, 2026 at 3:03 PM Shivam Kalra via B4 Relay
> <devnull+shivamkalra98.zohomail.in@kernel.org> 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.
>>
>> 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 <shivamkalra98@zohomail.in>
>> ---
>>  mm/vmalloc.c | 25 ++++++++++++++++++++-----
>>  1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 54e76a47e995..7a4c59422638 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -4327,14 +4327,29 @@ 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));
>> +
>> +                       kasan_poison_vmalloc(
>> +                               (void *)(addr + (new_nr_pages << PAGE_SHIFT)),
>> +                               (vm->nr_pages - new_nr_pages) << PAGE_SHIFT);
> 
> There is a kasan_poison_vmalloc() call here.
> 
>> +                       vmalloc_free_pages(vm, new_nr_pages, vm->nr_pages);
>> +                       vm->nr_pages = new_nr_pages;
>> +               }
>> +
>>                 vm->requested_size = size;
>>                 kasan_poison_vmalloc(p + size, old_size - size);
> 
> And there is a kasan_poison_vmalloc() call here.
> 
> Furthermore, they seem to touch overlapping ranges. Perhaps the first
> call can be dropped?
> 
> Alice
Thanks for the feedback Alice. I will do two things for v2.
1. Update the base-commit to the recent most commit on char-misc-next
2. Keep only a single `kasan_vrealloc` call after the rebase.