All of lore.kernel.org
 help / color / mirror / Atom feed
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com, 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: Sat, 20 Aug 2011 13:22:19 +0900	[thread overview]
Message-ID: <4E4F367B.8060904@hitachi.com> (raw)
In-Reply-To: <20110819155238.b11d19fb.akpm@linux-foundation.org>

Hi Paul and Andrew,

(2011/08/20 3:53), Paul E. McKenney wrote:
>> @@ -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?
>

(2011/08/20 7:52), Andrew Morton wrote:
> I think this is still just a workaround to fix up the real bug, and
> that the real bug is that the vm_struct is installed into the vmlist
> *before* it is fully initialised.  It's just wrong to insert an object
> into a globally-visible list and to then start populating it!  If we
> were instead to fully initialise the vm_struct and *then* insert it
> into vmlist, the bug is fixed.
>
> Also I'd agree with Paul's concern regarding cross-CPU memory ordering.
>

I deeply agreed with both of your concern and comments.
I'd like to create the patch where the vm_struct is installed into 
the vmlist *after* it is fully initialized.

Thanks.


(2011/08/20 7:52), Andrew Morton wrote:
> On Fri, 19 Aug 2011 19:51:33 +0900
> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> 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.
> 
> I think this is still just a workaround to fix up the real bug, and
> that the real bug is that the vm_struct is installed into the vmlist
> *before* it is fully initialised.  It's just wrong to insert an object
> into a globally-visible list and to then start populating it!  If we
> were instead to fully initialise the vm_struct and *then* insert it
> into vmlist, the bug is fixed.
> 
> Also I'd agree with Paul's concern regarding cross-CPU memory ordering.
> 


WARNING: multiple messages have this Message-ID (diff)
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com, 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: Sat, 20 Aug 2011 13:22:19 +0900	[thread overview]
Message-ID: <4E4F367B.8060904@hitachi.com> (raw)
In-Reply-To: <20110819155238.b11d19fb.akpm@linux-foundation.org>

Hi Paul and Andrew,

(2011/08/20 3:53), Paul E. McKenney wrote:
>> @@ -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?
>

(2011/08/20 7:52), Andrew Morton wrote:
> I think this is still just a workaround to fix up the real bug, and
> that the real bug is that the vm_struct is installed into the vmlist
> *before* it is fully initialised.  It's just wrong to insert an object
> into a globally-visible list and to then start populating it!  If we
> were instead to fully initialise the vm_struct and *then* insert it
> into vmlist, the bug is fixed.
>
> Also I'd agree with Paul's concern regarding cross-CPU memory ordering.
>

I deeply agreed with both of your concern and comments.
I'd like to create the patch where the vm_struct is installed into 
the vmlist *after* it is fully initialized.

Thanks.


(2011/08/20 7:52), Andrew Morton wrote:
> On Fri, 19 Aug 2011 19:51:33 +0900
> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> 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.
> 
> I think this is still just a workaround to fix up the real bug, and
> that the real bug is that the vm_struct is installed into the vmlist
> *before* it is fully initialised.  It's just wrong to insert an object
> into a globally-visible list and to then start populating it!  If we
> were instead to fully initialise the vm_struct and *then* insert it
> into vmlist, the bug is fixed.
> 
> Also I'd agree with Paul's concern regarding cross-CPU memory ordering.
> 

--
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-20  4:22 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
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 [this message]
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=4E4F367B.8060904@hitachi.com \
    --to=mitsuo.hayasaka.hu@hitachi.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=namhyung@gmail.com \
    --cc=paulmck@linux.vnet.ibm.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.