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

[Shivam Kalra]

On 19/05/26 23:37, Andrew Morton wrote:
> On Tue, 19 May 2026 17:42:13 +0530 Shivam Kalra via B4 Relay <devnull+shivamkalra98.zohomail.in@xxxxxxxxxx> wrote:
> 
>> This series implements the TODO in vrealloc() to unmap and free unused
>> pages when shrinking across a page boundary.
> 
> Thanks, I'll add this to mm.git's mm-new branch for testing.  A few
> days hence I'll hopefully move it into the mm-unstable branch for
> linux-next exposure.
> 
> Sashiko is still saying things.  Please double-check that it's all been
> dealt with and there's nothing new in there?
> 
> 	https://sashiko.dev/#/patchset/20260519-vmalloc-shrink-v14-0-70b96ee3e9c9@xxxxxxxxxxx
I've reviewed all five Sashiko findings:

- Issues 1+2 (32-bit shift overflow in nr_pages << PAGE_SHIFT):
  nr_pages is unsigned int; a pre-existing type choice in struct
  vm_struct. Uladzislau reviewed this and explicitly asked to
  drop the (size_t) cast in v11.

- Issue 3 (VM_ALLOC areas with nr_pages==0): Valid point.
  pcpu_get_vm_areas() creates VM_ALLOC areas but manages pages through
  its own path and never sets nr_pages. With patch 3, vread_iter would
  skip these areas instead of reading them; a minor /proc/kcore
  observability regression. I'll send a follow-up fix to fall back to
  get_vm_area_size() when nr_pages is 0.

- Issue 4 (kmemleak scanner race): __delete_object() clears
  OBJECT_ALLOCATED under object->lock, and
  scan_object() re-checks that flag under the same lock after
  cond_resched(). Additionally, kmemleak_free_part()
  is called before vunmap_range(), so pages are still mapped during
  any scan window.

- Issue 5 (__GFP_ZERO on grow-after-shrink): Not a regression per
  Sashiko's own assessment. The API doc already requires callers to
  consistently pass __GFP_ZERO for every call.