All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Namhyung Kim <namhyung@gmail.com>,
	David Rientjes <rientjes@google.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH v2] avoid null pointer access in vm_struct
Date: Fri, 19 Aug 2011 11:53:22 -0700	[thread overview]
Message-ID: <20110819185322.GI2401@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110819105133.7504.62129.stgit@ltc219.sdl.hitachi.co.jp>

On Fri, Aug 19, 2011 at 07:51:33PM +0900, Mitsuo Hayasaka wrote:
> The /proc/vmallocinfo shows information about vmalloc allocations in vmlist
> that is a linklist of vm_struct. It, however, may access pages field of
> vm_struct where a page was not allocated, which results in a null pointer
> access and leads to a kernel panic.
> 
> Why this happen:
> In __vmalloc_area_node(), the nr_pages field of vm_struct are set to the
> expected number of pages to be allocated, before the actual pages
> allocations. At the same time, when the /proc/vmallocinfo is read, it
> accesses the pages field of vm_struct according to the nr_pages field at
> show_numa_info(). Thus, a null pointer access happens.
> 
> Patch:
> This patch sets nr_pages field of vm_struct AFTER the pages allocations
> finished in __vmalloc_area_node(). So, it can avoid accessing the pages
> field with unallocated page when show_numa_info() is called.

One question below...

> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Namhyung Kim <namhyung@gmail.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
> 
>  mm/vmalloc.c |   10 +++++-----
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 7ef0903..49d8aed 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1529,7 +1529,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size = (nr_pages * sizeof(struct page *));
> 
> -	area->nr_pages = nr_pages;
>  	/* Please note that the recursion is strictly bounded. */
>  	if (array_size > PAGE_SIZE) {
>  		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
> @@ -1538,15 +1537,15 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	} else {
>  		pages = kmalloc_node(array_size, nested_gfp, node);
>  	}
> -	area->pages = pages;
> -	area->caller = caller;
> -	if (!area->pages) {
> +	if (!pages) {
>  		remove_vm_area(area->addr);
>  		kfree(area);
>  		return NULL;
>  	}
> +	area->pages = pages;
> +	area->caller = caller;
> 
> -	for (i = 0; i < area->nr_pages; i++) {
> +	for (i = 0; i < nr_pages; i++) {
>  		struct page *page;
>  		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;
> 
> @@ -1562,6 +1561,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  		}
>  		area->pages[i] = page;
>  	}

Don't we need something here to prevent the compiler and/or the CPU
from reordering the assignment?  Or am I missing how this is otherwise
prevented?

> +	area->nr_pages = nr_pages;
> 
>  	if (map_vm_area(area, prot, &pages))
>  		goto fail;
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Namhyung Kim <namhyung@gmail.com>,
	David Rientjes <rientjes@google.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH v2] avoid null pointer access in vm_struct
Date: Fri, 19 Aug 2011 11:53:22 -0700	[thread overview]
Message-ID: <20110819185322.GI2401@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110819105133.7504.62129.stgit@ltc219.sdl.hitachi.co.jp>

On Fri, Aug 19, 2011 at 07:51:33PM +0900, Mitsuo Hayasaka wrote:
> The /proc/vmallocinfo shows information about vmalloc allocations in vmlist
> that is a linklist of vm_struct. It, however, may access pages field of
> vm_struct where a page was not allocated, which results in a null pointer
> access and leads to a kernel panic.
> 
> Why this happen:
> In __vmalloc_area_node(), the nr_pages field of vm_struct are set to the
> expected number of pages to be allocated, before the actual pages
> allocations. At the same time, when the /proc/vmallocinfo is read, it
> accesses the pages field of vm_struct according to the nr_pages field at
> show_numa_info(). Thus, a null pointer access happens.
> 
> Patch:
> This patch sets nr_pages field of vm_struct AFTER the pages allocations
> finished in __vmalloc_area_node(). So, it can avoid accessing the pages
> field with unallocated page when show_numa_info() is called.

One question below...

> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Namhyung Kim <namhyung@gmail.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
> 
>  mm/vmalloc.c |   10 +++++-----
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 7ef0903..49d8aed 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1529,7 +1529,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size = (nr_pages * sizeof(struct page *));
> 
> -	area->nr_pages = nr_pages;
>  	/* Please note that the recursion is strictly bounded. */
>  	if (array_size > PAGE_SIZE) {
>  		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
> @@ -1538,15 +1537,15 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	} else {
>  		pages = kmalloc_node(array_size, nested_gfp, node);
>  	}
> -	area->pages = pages;
> -	area->caller = caller;
> -	if (!area->pages) {
> +	if (!pages) {
>  		remove_vm_area(area->addr);
>  		kfree(area);
>  		return NULL;
>  	}
> +	area->pages = pages;
> +	area->caller = caller;
> 
> -	for (i = 0; i < area->nr_pages; i++) {
> +	for (i = 0; i < nr_pages; i++) {
>  		struct page *page;
>  		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;
> 
> @@ -1562,6 +1561,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  		}
>  		area->pages[i] = page;
>  	}

Don't we need something here to prevent the compiler and/or the CPU
from reordering the assignment?  Or am I missing how this is otherwise
prevented?

> +	area->nr_pages = nr_pages;
> 
>  	if (map_vm_area(area, prot, &pages))
>  		goto fail;
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-08-19 18:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-19 10:51 [PATCH v2] avoid null pointer access in vm_struct Mitsuo Hayasaka
2011-08-19 10:51 ` Mitsuo Hayasaka
2011-08-19 18:53 ` Paul E. McKenney [this message]
2011-08-19 18:53   ` Paul E. McKenney
2011-08-19 22:52 ` Andrew Morton
2011-08-19 22:52   ` Andrew Morton
2011-08-20  4:22   ` HAYASAKA Mitsuo
2011-08-20  4:22     ` HAYASAKA Mitsuo

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=20110819185322.GI2401@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mitsuo.hayasaka.hu@hitachi.com \
    --cc=namhyung@gmail.com \
    --cc=rientjes@google.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /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.