From: ebiederm@xmission.com (Eric W. Biederman)
To: Simon Horman <horms@verge.net.au>
Cc: Jonathan Steel <jon.steel@esentire.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kexec, kernel 2.6.26.5, segmentation fault in kimage_add_entry
Date: Tue, 16 Sep 2008 19:40:55 -0700 [thread overview]
Message-ID: <m1tzcfa408.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <20080917005542.GD15750@verge.net.au> (Simon Horman's message of "Wed, 17 Sep 2008 10:55:42 +1000")
Simon Horman <horms@verge.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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-09-17 2:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-16 19:18 [PATCH] kexec, kernel 2.6.26.5, segmentation fault in kimage_add_entry Jonathan Steel
2008-09-16 22:21 ` [PATCH] kexec: " Eric W. Biederman
2008-09-18 4:30 ` Simon Horman
2008-09-17 0:55 ` [PATCH] kexec, kernel 2.6.26.5, " Simon Horman
2008-09-17 2:40 ` Eric W. Biederman [this message]
2008-09-17 13:18 ` Jonathan Steel
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=m1tzcfa408.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=jon.steel@esentire.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox