From: ebiederm@xmission.com (Eric W. Biederman)
To: vatsa@in.ibm.com
Cc: Dipankar Sarma <dipankar@in.ibm.com>,
Andrew Morton <akpm@osdl.org>,
suparna@in.ibm.com, ebiederm@xmission.com, mbligh@aracnet.com,
fastboot@osdl.org, litke@us.ibm.com,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] Re: [PATCH][4/6]Register snapshotting before kexec boot
Date: 19 Sep 2004 14:17:58 -0600 [thread overview]
Message-ID: <m1hdpu813d.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040917145350.GA4750@in.ibm.com>
Srivatsa Vaddagiri <vatsa@in.ibm.com> writes:
> On Thu, Sep 16, 2004 at 08:41:13AM +0000, Dipankar Sarma wrote:
> > On Wed, Sep 15, 2004 at 02:27:22PM -0700, Andrew Morton wrote:
> > > Is dodgy wrt CPU hotplug, but there's not a lot we can do about that
> > > in this context, I expect. Which is a shame, given that CPU hotplug
> > > is a likely time at which to be taking a crashdump ;)
> >
> > If Hari disables preemption during this entire section of code,
> > he should be safe from CPU hotplug, AFAICS. The stop machine
> > threads will never get to run on that CPU.
>
> This will work for CPU remove, not CPU add, since the later
> is not atomic (yet).
>
> Rusty, do you think it would be worthwhile making CPU add atomic?
> I can give it a shot :)
The whole section should be run with interrupts disabled,
so disabling preemption should be trivial.
Beyond this the code needs a bogomips based timeout, (we can't use external
time sources just the delay loop). Any of the other cpu's could have
crashed at this point, or our accounting data structures could be
currupt.
Putting the initial call inside of machine_kexec is also bogus.
crash_machine_kexec needs to call crash_stop_cpus and then
machine_kexec. machine_kexec is currently factored as a perfectly
reusable piece of code let's not mess that up.
Eric
next prev parent reply other threads:[~2004-09-19 20:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 12:50 kexec based crash dumping Hariprasad Nellitheertha
2004-09-15 12:51 ` [PATCH][1/6]Documentation Hariprasad Nellitheertha
2004-09-15 12:53 ` [PATCH][2/6]Memory preserving reboot using kexec Hariprasad Nellitheertha
2004-09-15 12:54 ` [PATCH][3/6]Routines for copying the dump pages Hariprasad Nellitheertha
2004-09-15 12:55 ` [PATCH][4/6]Register snapshotting before kexec boot Hariprasad Nellitheertha
2004-09-15 12:56 ` [PATCH][5/6]ELF format dump file access Hariprasad Nellitheertha
2004-09-15 12:57 ` [PATCH][6/6]Linear/raw " Hariprasad Nellitheertha
2004-09-15 21:28 ` [PATCH][5/6]ELF " Andrew Morton
2004-09-15 21:29 ` Andrew Morton
2004-09-15 21:31 ` Andrew Morton
2004-09-15 21:27 ` [PATCH][4/6]Register snapshotting before kexec boot Andrew Morton
2004-09-16 8:11 ` [Fastboot] " Dipankar Sarma
2004-09-17 14:53 ` Srivatsa Vaddagiri
2004-09-19 20:17 ` Eric W. Biederman [this message]
2004-09-15 21:23 ` [PATCH][3/6]Routines for copying the dump pages Andrew Morton
2004-09-15 21:22 ` [PATCH][2/6]Memory preserving reboot using kexec Andrew Morton
2004-09-19 20:37 ` [Fastboot] " Eric W. Biederman
2004-09-20 13:49 ` Hariprasad Nellitheertha
2004-09-20 19:53 ` Eric W. Biederman
2004-09-15 17:33 ` [Fastboot] kexec based crash dumping 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=m1hdpu813d.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=litke@us.ibm.com \
--cc=mbligh@aracnet.com \
--cc=rusty@rustcorp.com.au \
--cc=suparna@in.ibm.com \
--cc=vatsa@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.