All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: shivamkalra98@zohomail.in
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alice Ryhl <aliceryhl@google.com>,
	Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH v8 4/6] mm/vmalloc: use READ_ONCE() for vmalloc nr_pages status readers
Date: Tue, 31 Mar 2026 19:43:14 +0200	[thread overview]
Message-ID: <acwHshfg9vEUFaer@milan> (raw)
In-Reply-To: <20260327-vmalloc-shrink-v8-4-cc6b57059ed7@zohomail.in>

On Fri, Mar 27, 2026 at 03:18:40PM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
> 
> The vmalloc status readers (vmalloc_info_show(), show_numa_info(), and
> vmalloc_dump_obj()) currently read v->nr_pages and the v->pages array
> without any concurrent protection.
> 
> In preparation for vrealloc() shrink support, where v->nr_pages can
> be decreased and entries in the v->pages array can be nulled out
> concurrently, these readers must be protected to prevent use-after-free
> or NULL pointer dereferences.
> 
> Update these functions to use READ_ONCE() when accessing v->nr_pages
> and v->pages[nr]. This ensures the compiler does not re-fetch these
> values and provides a consistent view of the vmap area's state.
> Additionally, in show_numa_info(), explicitly check for a NULL page
> pointer before dereferencing it to avoid potential crashes if a page
> was concurrently removed during a shrink operation.
> 
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
>  mm/vmalloc.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ddb689bf9ba5..c6bdddee6266 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -5189,7 +5189,7 @@ bool vmalloc_dump_obj(void *object)
>  	vm = va->vm;
>  	addr = (unsigned long) vm->addr;
>  	caller = vm->caller;
> -	nr_pages = vm->nr_pages;
> +	nr_pages = READ_ONCE(vm->nr_pages);
>  	spin_unlock(&vn->busy.lock);
>  
Here is it protected by the spin-lock.

>  	pr_cont(" %u-page vmalloc region starting at %#lx allocated at %pS\n",
> @@ -5210,7 +5210,7 @@ bool vmalloc_dump_obj(void *object)
>  static void show_numa_info(struct seq_file *m, struct vm_struct *v,
>  				 unsigned int *counters)
>  {
> -	unsigned int nr;
> +	unsigned int nr, nr_pages;
>  	unsigned int step = 1U << vm_area_page_order(v);
>  
>  	if (!counters)
> @@ -5218,8 +5218,13 @@ static void show_numa_info(struct seq_file *m, struct vm_struct *v,
>  
>  	memset(counters, 0, nr_node_ids * sizeof(unsigned int));
>  
> -	for (nr = 0; nr < v->nr_pages; nr += step)
> -		counters[page_to_nid(v->pages[nr])] += step;
> +	nr_pages = READ_ONCE(v->nr_pages);
> +	for (nr = 0; nr < nr_pages; nr += step) {
>
show_numa_info() also is protected:

	if (IS_ENABLED(CONFIG_NUMA))
		show_numa_info(m, v, counters);

	seq_putc(m, '\n');
 }	
 spin_unlock(&vn->busy.lock);

> +		struct page *page = READ_ONCE(v->pages[nr]);
> +
> +		if (page)
> +			counters[page_to_nid(page)] += step;
> +	}
>  	for_each_node_state(nr, N_HIGH_MEMORY)
>  		if (counters[nr])
>  			seq_printf(m, " N%u=%u", nr, counters[nr]);
> @@ -5247,6 +5252,7 @@ static int vmalloc_info_show(struct seq_file *m, void *p)
>  	struct vmap_area *va;
>  	struct vm_struct *v;
>  	unsigned int *counters;
> +	unsigned int nr_pages;
>  
>  	if (IS_ENABLED(CONFIG_NUMA))
>  		counters = kmalloc_array(nr_node_ids, sizeof(unsigned int), GFP_KERNEL);
> @@ -5276,8 +5282,9 @@ static int vmalloc_info_show(struct seq_file *m, void *p)
>  			if (v->caller)
>  				seq_printf(m, " %pS", v->caller);
>  
> -			if (v->nr_pages)
> -				seq_printf(m, " pages=%d", v->nr_pages);
> +			nr_pages = READ_ONCE(v->nr_pages);
> +			if (nr_pages)
> +				seq_printf(m, " pages=%d", nr_pages);
>  
>  			if (v->phys_addr)
>  				seq_printf(m, " phys=%pa", &v->phys_addr);
> 
>
vmalloc_info_show() is also protected.

I do not see why we need this patch. Am i missing something?

--
Uladzislau Rezki


  reply	other threads:[~2026-03-31 17:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27  9:48 [PATCH v8 0/6] mm/vmalloc: free unused pages on vrealloc() shrink Shivam Kalra
2026-03-27  9:48 ` Shivam Kalra via B4 Relay
2026-03-27  9:48 ` [PATCH v8 1/6] mm/vmalloc: extract vm_area_free_pages() helper from vfree() Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-31 17:44   ` Uladzislau Rezki
2026-03-27  9:48 ` [PATCH v8 2/6] mm/vmalloc: fix vrealloc() grow-in-place check Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-27  9:48 ` [PATCH v8 3/6] mm/vmalloc: zero newly exposed memory on vrealloc() grow Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-27  9:48 ` [PATCH v8 4/6] mm/vmalloc: use READ_ONCE() for vmalloc nr_pages status readers Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-31 17:43   ` Uladzislau Rezki [this message]
2026-03-27  9:48 ` [PATCH v8 5/6] mm/vmalloc: free unused pages on vrealloc() shrink Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-27  9:48 ` [PATCH v8 6/6] lib/test_vmalloc: add vrealloc test case Shivam Kalra
2026-03-27  9:48   ` Shivam Kalra via B4 Relay
2026-03-31 17:45   ` Uladzislau Rezki
2026-03-27 18:37 ` [PATCH v8 0/6] mm/vmalloc: free unused pages on vrealloc() shrink Andrew Morton
2026-03-27 19:31   ` Danilo Krummrich
2026-03-30  8:05   ` Alice Ryhl
2026-03-30 12:27     ` Uladzislau Rezki
2026-03-31 17:15       ` Shivam Kalra
2026-03-31 17:50         ` Uladzislau Rezki
2026-03-31 19:23           ` Shivam Kalra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acwHshfg9vEUFaer@milan \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shivamkalra98@zohomail.in \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.