[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrW2=xk+YMjH9AGMn7H1tQZb6XL5hrgNcttKS=ruyt44fA@mail.gmail.com>
Date: Wed, 14 May 2014 15:51:59 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Sasha Levin <sasha.levin@...cle.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Dave Jones <davej@...hat.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: mm: NULL ptr deref handling mmaping of special mappings
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin <sasha.levin@...cle.com> wrote:
>
>> > In my linux-next all that code got deleted by Andy's "x86, vdso:
>> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
>> > were you looking at?
>>
>> Deleted? It appears in today's -next. arch/x86/vdso/vma.c:124 .
>>
>> I don't see Andy's patch removing that code either.
>
> ah, OK, it got moved from arch/x86/vdso/vdso32-setup.c into
> arch/x86/vdso/vma.c.
>
> Maybe you managed to take a fault against the symbol area between the
> _install_special_mapping() and the remap_pfn_range() call, but mmap_sem
> should prevent that.
>
> Or the remap_pfn_range() call never happened. Should map_vdso() be
> running _install_special_mapping() at all if
> image->sym_vvar_page==NULL?
You're almost right, but that was enough to point me in the right direction :)
The mapping is still needed, since there are two pages. qemu -no-hpet
will trigger this, but the nohpet kernel option will not. The latter
is arguably a bug in the nohpet option.
Fix coming.
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists