[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1tzcfa408.fsf@frodo.ebiederm.org>
Date: Tue, 16 Sep 2008 19:40:55 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Simon Horman <horms@...ge.net.au>
Cc: Jonathan Steel <jon.steel@...ntire.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kexec, kernel 2.6.26.5, segmentation fault in kimage_add_entry
Simon Horman <horms@...ge.net.au> writes:
> On Tue, Sep 16, 2008 at 03:18:23PM -0400, Jonathan Steel wrote:
>> A segmentation fault can occur in kimage_add_entry in kexec.c when
>> loading a kernel image into memory. The fault occurs because a page is
>> requested by calling kimage_alloc_page with gfp_mask GFP_KERNEL and the
>> function may actually return a page with gfp_mask GFP_HIGHUSER. The high
>> mem page is returned because it was swapped with the kernel page due to
>> the kernel page being a page that will shortly be copied to.
>>
>> This patch ensures that kimage_alloc_page returns a page that was
>> created with the correct gfp flags.
>
> I wonder if this problem might also affect other users of
> kimage_alloc_pages(), and if so, perhaps it should guard
> against this?
No. kimage_alloc_pages() is a light wrapper around alloc_pages that simply
marks the pages as reserved so they don't get used for other things while
we have a hold of them.
kimage_alloc_page() does a check to see if the page we have just allocated
is the a page we are going to copy to and if so it does the copy of the
data now, and frees the page that was holding the data.
As an optimization it returns the page holding the data. The problem is that
we allocate control pages as GFP_KERNEL and data pages GFP_HIGHUSER. And so
they are not completely interchangeable.
Since this check and swap only happens inside of kimage_alloc_page it only affects
kimage_alloc_page.
Eric
n
--
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