From: Vivek Goyal <vgoyal@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
fastboot <fastboot@lists.osdl.org>
Cc: lkml <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>
Subject: [RFC/PATCH 1/17][kexec-tools-1.101] vmlinux parameter segment stomping fix
Date: Mon, 28 Mar 2005 18:55:53 +0530 [thread overview]
Message-ID: <1112016353.4001.72.camel@localhost.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: kexec-tools-vmlinux-parameter-segment-stomping-fix.patch --]
[-- Type: text/x-patch, Size: 2026 bytes --]
During loading of panic kernel(vmlinux), it was found that on some systems,
parameter segment was being stomped over by kernel. This was resulting in
corruption of e820 memory map and leading to boot memory allocator
initialization failures while booting into new kernel. This patch fixes the
problem by loading the parameter segment beyond alrady loaded kernel image
and setup code. A 64K buffer has been provided to avoid any stomping by
kernel.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
kexec-tools-1.101-root/kexec/arch/i386/kexec-elf-x86.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff -puN kexec/arch/i386/kexec-elf-x86.c~kexec-tools-vmlinux-parameter-segment-stomping-fix kexec/arch/i386/kexec-elf-x86.c
--- kexec-tools-1.101/kexec/arch/i386/kexec-elf-x86.c~kexec-tools-vmlinux-parameter-segment-stomping-fix 2005-03-21 16:43:50.000000000 +0530
+++ kexec-tools-1.101-root/kexec/arch/i386/kexec-elf-x86.c 2005-03-21 16:43:50.000000000 +0530
@@ -199,15 +199,27 @@ int elf_x86_load(int argc, char **argv,
}
else if (arg_style == ARG_STYLE_LINUX) {
struct x86_linux_faked_param_header *hdr;
- unsigned long param_base;
+ unsigned long param_base, min_param_base = 0;
const unsigned char *ramdisk_buf;
off_t ramdisk_length;
struct entry32_regs regs;
+ int i;
/* Get the linux parameter header */
hdr = xmalloc(sizeof(*hdr));
+ /* Add parameter segment beyond already loaded segments, so that
+ * it does not get stomped by kernel. */
+ for (i = 0; i < info->nr_segments; i++) {
+ unsigned long temp;
+ temp = (unsigned long) info->segment[i].mem +
+ info->segment[i].memsz;
+ if (temp > min_param_base)
+ min_param_base = temp;
+ }
+ /* 64K of buffer to keep enough distance from kernel. */
+ min_param_base += 64*1024;
param_base = add_buffer(info, hdr, sizeof(*hdr), sizeof(*hdr),
- 16, 0, max_addr, 1);
+ 16, min_param_base, max_addr, 1);
/* Initialize the parameter header */
memset(hdr, 0, sizeof(*hdr));
_
next reply other threads:[~2005-03-28 13:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-28 13:25 Vivek Goyal [this message]
2005-07-18 18:21 ` [Fastboot] " Eric W. Biederman
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=1112016353.4001.72.camel@localhost.localdomain \
--to=vgoyal@in.ibm.com \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.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
all inboxes | Powered by JetHome®