From: "Fernando Luis Vázquez Cao" <fernando@oss.ntt.co.jp>
To: vgoyal@in.ibm.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
akpm@osdl.org, ak@suse.de, James.Bottomley@steeleye.com,
linux-kernel@vger.kernel.org, fastboot@lists.osdl.org
Subject: [PATCH 0/4] stack overflow safe kdump (2.6.18-rc1-i386) try#2
Date: Tue, 11 Jul 2006 15:04:44 +0900 [thread overview]
Message-ID: <1152597884.2414.53.camel@localhost.localdomain> (raw)
Hi,
I tried to incorporate all the ideas received after the previous post
(thank you!). In particular I hope the new code is handling the Voyager
case properly.
---
This is a the first of a series of patch-sets aiming at making kdump
more robust against stack overflows.
This patch set does the following:
* Add safe_smp_processor_id function to i386 architecture (this function
was inspired by the x86_64 function of the same name).
* Substitute "smp_processor_id" with the stack overflow-safe
"safe_smp_processor_id" in the reboot path to the second kernel.
List of patches (the last two should be applied in the order of
appearance):
[1/4] safe_smp_processor_id: stack overflow safe implementation of
smp_processor_id.
[2/4] safe_smp_processor_id_voyager: stack overflow safe implementation
of smp_processor_id for i386-voyager.
[3/4] crash_use_safe_smp_processor_id: replace smp_processor_id with
safe_smp_processor_id in "arch/i386/kernel/crash.c".
[4/4] safe_smp_send_nmi_allbutself: re-implement smp_send_nmi_allbutself
so that calls to smp_processor_id (through send_IPI_allbutself) can be
replaced with safe_smp_processor_id without affecting other parts of the
kernel (as suggested by Eric Biederman).
I am looking forward to your comments and suggestions.
Regards,
Fernando
next reply other threads:[~2006-07-11 6:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 6:04 Fernando Luis Vázquez Cao [this message]
2006-07-11 6:59 ` [PATCH 0/4] stack overflow safe kdump (2.6.18-rc1-i386) try#2 Andi Kleen
2006-07-11 7:13 ` 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=1152597884.2414.53.camel@localhost.localdomain \
--to=fernando@oss.ntt.co.jp \
--cc=James.Bottomley@steeleye.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.