From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx184.postini.com [74.125.245.184]) by kanga.kvack.org (Postfix) with SMTP id 58322940001 for ; Fri, 25 May 2012 07:12:42 -0400 (EDT) Received: by lbjn8 with SMTP id n8so810706lbj.14 for ; Fri, 25 May 2012 04:12:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <002c01cd3a0c$aef39530$0cdabf90$@codeaurora.org> References: <001c01cd3987$d1a71a50$74f54ef0$%cho@samsung.com> <20120524151231.e3a18ac5.akpm@linux-foundation.org> <002c01cd3a0c$aef39530$0cdabf90$@codeaurora.org> Date: Fri, 25 May 2012 20:12:40 +0900 Message-ID: Subject: mm: fix faulty initialization in vmalloc_init() From: KyongHo Cho Content-Type: multipart/alternative; boundary=f46d04426e9050826b04c0da72d5 Sender: owner-linux-mm@kvack.org List-ID: To: Olav Haugan Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" --f46d04426e9050826b04c0da72d5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 25, 2012 at 9:24 AM, Olav Haugan wrote: >> -----Original Message----- >> On Thu, 24 May 2012 17:32:56 +0900 >> KyongHo wrote: >> >> > --- a/mm/vmalloc.c >> > +++ b/mm/vmalloc.c >> > @@ -1185,9 +1185,10 @@ void __init vmalloc_init(void) >> > /* Import existing vmlist entries. */ >> > for (tmp = vmlist; tmp; tmp = tmp->next) { >> > va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT); > > - va->flags = tmp->flags | VM_VM_AREA; >> > + va->flags = VM_VM_AREA; >> >> This change is a mystery. Why do we no longer transfer ->flags? > > I was actually debugging the same exact issue today. This transfer of flags > actually causes some of the static mapping virtual addresses to be > prematurely freed (before the mapping is removed) because VM_LAZY_FREE gets > "set" if tmp->flags has VM_IOREMAP set. This might cause subsequent > vmalloc/ioremap calls to fail because it might allocate one of the freed > virtual address ranges that aren't unmapped. > Thanks for description. va->flags has different types of flags from tmp->flags. If a region with VM_IOREMAP set is registered with vm_area_add_early(), it will be removed by __purge_vmap_area_lazy(). Cho KyongHo. --f46d04426e9050826b04c0da72d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 25, 2012 at 9:24 AM, Olav Haugan <ohaugan@codeaurora.org> wrote:
>> -----Orig= inal Message-----
>> On Thu, 24 May 2012 17:32:56 +0900
>>= ; KyongHo <pullip.cho@samsung.= com> wrote:
>>
>> > --- a/mm/vmalloc.c
>> > +++ b/mm/vmal= loc.c
>> > @@ -1185,9 +1185,10 @@ void __init vmalloc_init(void= )
>> > =A0 =A0 /* Import existing vmlist entries. */
>>= ; > =A0 =A0 for (tmp =3D vmlist; tmp; tmp =3D tmp->next) {
>> > =A0 =A0 =A0 =A0 =A0 =A0 va =3D kzalloc(sizeof(struct vmap_are= a), GFP_NOWAIT);
> =A0> - =A0 =A0 =A0 =A0 =A0 =A0va->flags =3D = tmp->flags | VM_VM_AREA;
>> > + =A0 =A0 =A0 =A0 =A0 va->f= lags =3D VM_VM_AREA;
>>
>> This change is a mystery. =A0W= hy do we no longer transfer ->flags?
>
> I was actually debugging the same exact issue today. This tran= sfer of flags
> actually causes some of the static mapping virtual ad= dresses to be
> prematurely freed (before the mapping is removed) bec= ause VM_LAZY_FREE gets
> "set" if tmp->flags has VM_IOREMAP set. This might cause = subsequent
> vmalloc/ioremap calls to fail because it might allocate = one of the freed
> virtual address ranges that aren't unmapped. >
Thanks for description.

va->flags has different types of = flags from tmp->flags.
If a region with VM_IOREMAP set is registered = with vm_area_add_early(),
it will be removed by __purge_vmap_area_lazy()= .

=A0Cho KyongHo.

--f46d04426e9050826b04c0da72d5-- -- 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: email@kvack.org