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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox