From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] kexec: return error of machine_kexec() fails
Date: Thu, 11 Jul 2013 00:51:47 +0100 [thread overview]
Message-ID: <20130710235147.GZ24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <87txk2cfkm.fsf@xmission.com>
On Wed, Jul 10, 2013 at 01:42:17PM -0700, Eric W. Biederman wrote:
> I meant code not hardware architecture. We keep having code thrown in
> the the shutdown paths because ARM only supports cpu shutdown via cpu
> hotunplug and cpu hotunplug is not universally available.
>
> That is a software architecture BUG with the ARM kernels.
There are many problems here:
1) if you can't place a CPU individually into reset, what do you do with
it over a kexec?
Once woken it executes code. It will never stop executing code. If you
place it inside an infinite loop in the existing kernel, and then
overwrite it, it will then start executing the instructions there when
the new kernel broadcasts the cache flushes, and it will start executing
whatever code is there.
2) if the CPU itself needs to execute code to shut itself down, how do
you get it to do that on a crash-based kexec when IPI broadcasts may not
work?
3) what about situations where you need the requestor to also do something
to shut down the secondary CPU?
Taking CPUs offline is not an easy thing to do when every platform plays
their own games with doing that, and then you have security crap that
gets in the way too, with the security crap having platform specific
interfaces.
CPU hotplug is by far the best solution we have to this mess.
prev parent reply other threads:[~2013-07-10 23:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1373421296-6112-1-git-send-email-horms@verge.net.au>
[not found] ` <87obaaiiry.fsf@xmission.com>
2013-07-10 19:09 ` [PATCH] kexec: return error of machine_kexec() fails Stephen Warren
2013-07-10 20:42 ` Eric W. Biederman
2013-07-10 23:51 ` Russell King - ARM Linux [this message]
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=20130710235147.GZ24642@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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