Re: [PATCH v4] mm/vmalloc: make vm_struct.nr_pages an unsigned long

On Sun, 2 Aug 2026 17:52:26 +0200 Uladzislau Rezki <[email protected]> wrote:

> On Sat, Aug 01, 2026 at 11:52:02AM -0700, Andrew Morton wrote:
> > On Sat,  1 Aug 2026 14:49:15 +0300 Artem Lytkin <[email protected]> wrote:
> > 
>
> ...
>
> > Ulad, AI review suggests that vrealloc() has an issue handling
> > __GFP_ZERO.  Can you please check?
> > 
> > 	https://sashiko.dev/#/patchset/[email protected]
> > 
> I have checked. I think the AI is missing at least one point.
> AI argument which is:
> 
> <snip>
> 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.
> <snip>
> 
> In the vrealloc_node_align_noprof() header documentation there is a statement:
> 
> <snip>
>  * 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.
> <snip>
> 
> AI argument violates the documentation, i.e. mixing __GFP_ZERO is not allowed.

Sashiko is talking about the initial allocation not using __GFP_ZERO
but vrealloc() *does* use __GFP_ZERO.  The documentation you quoted
doesn't address that case?

Also, developers don't read documentation ;) What happens if some
caller *does* use vmalloc(!__GFP_ZERO) then vrealloc(__GFP_ZERO)? 
Silent misbehavior would be bad - it would be good if vrealloc() were
to drop a WARN() then ignore the __GFP_ZERO.

> --- 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;
>  	}

OK, thanks, I'll assume you'll prepare this for real when convenient.