linux.git/arch/arm/kernel/machine_kexec.c, branch v3.16.81 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ARM: kexec: fix failure to boot crash kernel 2017-11-11T13:33:02+00:00 Russell King rmk+kernel@armlinux.org.uk 2017-07-19T22:09:58+00:00 4053c6292e6991e9241f221ce5b4a0e771f7118d commit 0d70262a2d60886da6fe5b1fc8bbcd76cbbc306d upstream. When kexec was converted to DTB, the dtb address was passed between machine_kexec_prepare() and machine_kexec() using a static variable. This is bad news if you load a crash kernel followed by a normal kernel or vice versa - the last loaded kernel overwrites the dtb address. This can result in kexec failures, as (eg) we try to boot the crash kernel with the last loaded dtb. For example, with: the crash kernel fails to find the dtb. Avoid this by defining a kimage architecture structure, and store the address to be passed in r2 there, which will either be the ATAGs or the dtb blob. Fixes: 4cabd1d9625c ("ARM: 7539/1: kexec: scan for dtb magic in segments") Fixes: 42d720d1731a ("ARM: kexec: Make .text R/W in machine_kexec") Reported-by: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 0d70262a2d60886da6fe5b1fc8bbcd76cbbc306d upstream.

When kexec was converted to DTB, the dtb address was passed between
machine_kexec_prepare() and machine_kexec() using a static variable.
This is bad news if you load a crash kernel followed by a normal
kernel or vice versa - the last loaded kernel overwrites the dtb
address.

This can result in kexec failures, as (eg) we try to boot the crash
kernel with the last loaded dtb.  For example, with:

the crash kernel fails to find the dtb.

Avoid this by defining a kimage architecture structure, and store
the address to be passed in r2 there, which will either be the ATAGs
or the dtb blob.

Fixes: 4cabd1d9625c ("ARM: 7539/1: kexec: scan for dtb magic in segments")
Fixes: 42d720d1731a ("ARM: kexec: Make .text R/W in machine_kexec")
Reported-by: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ARM: kexec: Make .text R/W in machine_kexec 2017-11-11T13:33:01+00:00 Nikolay Borisov Nikolay.Borisov@arm.com 2014-05-12T09:31:56+00:00 aa9a2ec0e82b64db1851d96ab1e9c83f8ea17a39 commit 42d720d1731a9d7035c2812437c35e271ec4dd78 upstream. With the introduction of Kees Cook's patch to make the kernel .text read-only the existing method by which kexec works got broken since it directly pokes some values in the template code, which resides in the .text section. The current patch changes the way those values are inserted so that poking .text section occurs only in machine_kexec (e.g when we are about to nuke the old kernel and are beyond the point of return). This allows to use set_kernel_text_rw() to directly patch the values in the .text section. I had already sent a patch which achieved this but it was significantly more complicated, so this is a cleaner/straight-forward approach. Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> [kees: collapsed kexec_boot_atags (will.daecon)] [kees: for bisectability, moved set_kernel_text_rw() to RODATA patch] Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 42d720d1731a9d7035c2812437c35e271ec4dd78 upstream.

With the introduction of Kees Cook's patch to make the kernel .text
read-only the existing method by which kexec works got broken since it
directly pokes some values in the template code, which resides in the
.text section.

The current patch changes the way those values are inserted so that poking
.text section occurs only in machine_kexec (e.g when we are about to nuke
the old kernel and are beyond the point of return). This allows to use
set_kernel_text_rw() to directly patch the values in the .text section.

I had already sent a patch which achieved this but it was significantly
more complicated, so this is a cleaner/straight-forward approach.

Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
[kees: collapsed kexec_boot_atags (will.daecon)]
[kees: for bisectability, moved set_kernel_text_rw() to RODATA patch]
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ARM: 8030/1: ARM : kdump : add arch_crash_save_vmcoreinfo 2014-04-22T21:23:58+00:00 Liu Hua sdu.liu@huawei.com 2014-04-18T06:45:36+00:00 56b700fd6f1e49149880fb1b6ffee0dca5be45fb For vmcore generated by LPAE enabled kernel, user space utility such as crash needs additional infomation to parse. So this patch add arch_crash_save_vmcoreinfo as what PAE enabled i386 linux does. Cc: <stable@vger.kernel.org> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Liu Hua <sdu.liu@huawei.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
For vmcore generated by LPAE enabled kernel, user space
utility such as crash needs additional infomation to
parse.

So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
i386 linux does.

Cc: <stable@vger.kernel.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel 2013-11-30T22:21:02+00:00 Dave Martin dave.martin@linaro.org 2013-11-25T13:54:47+00:00 e2ccba49085ab5d71b092de2a5176eb9b19cc876 Copying a function with memcpy() and then trying to execute the result isn't trivially portable to Thumb. This patch modifies the kexec soft restart code to copy its assembler trampoline relocate_new_kernel() using fncpy() instead, so that relocate_new_kernel can be in the same ISA as the rest of the kernel without problems. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Tested-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Copying a function with memcpy() and then trying to execute the
result isn't trivially portable to Thumb.

This patch modifies the kexec soft restart code to copy its
assembler trampoline relocate_new_kernel() using fncpy() instead,
so that relocate_new_kernel can be in the same ISA as the rest of
the kernel without problems.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Tested-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7815/1: kexec: offline non panic CPUs on Kdump panic 2013-08-19T23:14:46+00:00 Vijaya Kumar K vijay.kilari@gmail.com 2013-08-14T12:28:28+00:00 4f9b4fb7a2091eec339413a460b1665758401828 In case of normal kexec kernel load, all cpu's are offlined before calling machine_kexec().But in case crash panic cpus are relaxed in machine_crash_nonpanic_core() SMP function but not offlined. When crash kernel is loaded with kexec and on panic trigger machine_kexec() checks for number of cpus online. If more than one cpu is online machine_kexec() fails to load with below error kexec: error: multiple CPUs still online In machine_crash_nonpanic_core() SMP function, offline CPU before cpu_relax Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
In case of normal kexec kernel load, all cpu's are offlined
before calling machine_kexec().But in case crash panic cpus
are relaxed in machine_crash_nonpanic_core() SMP function
but not offlined.

When crash kernel is loaded with kexec and on panic trigger
machine_kexec() checks for number of cpus online.
If more than one cpu is online machine_kexec() fails to load
with below error

kexec: error: multiple CPUs still online

In machine_crash_nonpanic_core() SMP function, offline CPU
before cpu_relax

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7807/1: kexec: validate CPU hotplug support 2013-08-13T19:23:18+00:00 Stephen Warren swarren@nvidia.com 2013-08-02T19:52:49+00:00 2103f6cba61a8b8bea3fc1b63661d830a2125e76 Architectures should fully validate whether kexec is possible as part of machine_kexec_prepare(), so that user-space's kexec_load() operation can report any problems. Performing validation in machine_kexec() itself is too late, since it is not allowed to return. Prior to this patch, ARM's machine_kexec() was testing after-the-fact whether machine_kexec_prepare() was able to disable all but one CPU. Instead, modify machine_kexec_prepare() to validate all conditions necessary for machine_kexec_prepare()'s to succeed. BUG if the validation succeeded, yet disabling the CPUs didn't actually work. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Architectures should fully validate whether kexec is possible as part of
machine_kexec_prepare(), so that user-space's kexec_load() operation can
report any problems. Performing validation in machine_kexec() itself is
too late, since it is not allowed to return.

Prior to this patch, ARM's machine_kexec() was testing after-the-fact
whether machine_kexec_prepare() was able to disable all but one CPU.
Instead, modify machine_kexec_prepare() to validate all conditions
necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
succeeded, yet disabling the CPUs didn't actually work.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7759/1: decouple CPU offlining from reboot/shutdown 2013-06-17T20:35:25+00:00 Stephen Warren swarren@nvidia.com 2013-06-14T15:14:14+00:00 19ab428f4b7988ef3ac727c680efc193ef53ce14 Add comments to machine_shutdown()/halt()/power_off()/restart() that describe their purpose and/or requirements re: CPUs being active/not. In machine_shutdown(), replace the call to smp_send_stop() with a call to disable_nonboot_cpus(). This completely disables all but one CPU, thus satisfying the requirement that only a single CPU be active for kexec. Adjust Kconfig dependencies for this change. In machine_halt()/power_off()/restart(), call smp_send_stop() directly, rather than via machine_shutdown(); these functions don't need to completely de-activate all CPUs using hotplug, but rather just quiesce them. Remove smp_kill_cpus(), and its call from smp_send_stop(). smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling smp_ops.cpu_die() on the target CPUs first. At least some implementations of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra, for example. Since smp_send_stop() is only used for shutdown, halt, and power-off, there is no need to attempt any kind of CPU hotplug here. Adjust Kconfig to reflect that machine_shutdown() (and hence kexec) relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee that hotplug will work, or even that hotplug is implemented for a particular piece of HW that a multi-platform zImage runs on. Hence, add error-checking to machine_kexec() to determine whether it did work. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Zhangfei Gao <zhangfei.gao@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Add comments to machine_shutdown()/halt()/power_off()/restart() that
describe their purpose and/or requirements re: CPUs being active/not.

In machine_shutdown(), replace the call to smp_send_stop() with a call to
disable_nonboot_cpus(). This completely disables all but one CPU, thus
satisfying the requirement that only a single CPU be active for kexec.
Adjust Kconfig dependencies for this change.

In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
rather than via machine_shutdown(); these functions don't need to
completely de-activate all CPUs using hotplug, but rather just quiesce
them.

Remove smp_kill_cpus(), and its call from smp_send_stop().
smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
smp_ops.cpu_die() on the target CPUs first. At least some implementations
of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
for example. Since smp_send_stop() is only used for shutdown, halt, and
power-off, there is no need to attempt any kind of CPU hotplug here.

Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
that hotplug will work, or even that hotplug is implemented for a
particular piece of HW that a multi-platform zImage runs on. Hence, add
error-checking to machine_kexec() to determine whether it did work.

Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by:  Zhangfei Gao <zhangfei.gao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7555/1: kexec: fix segment memory addresses check 2012-10-18T10:05:19+00:00 Aaro Koskinen aaro.koskinen@iki.fi 2012-10-16T18:35:14+00:00 2456f44dd7a9aaffc2cd21a13f78198b3d94da08 Commit c564df4db85aac8d1d65a56176a0a25f46138064 (ARM: 7540/1: kexec: Check segment memory addresses) added a safety check with accidentally reversed condition, and broke kexec functionality on ARM. Fix this. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Commit c564df4db85aac8d1d65a56176a0a25f46138064 (ARM: 7540/1: kexec:
Check segment memory addresses) added a safety check with accidentally
reversed condition, and broke kexec functionality on ARM. Fix this.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7540/1: kexec: Check segment memory addresses 2012-09-26T21:58:39+00:00 Matthew Leach matthew.leach@arm.com 2012-09-21T17:56:11+00:00 c564df4db85aac8d1d65a56176a0a25f46138064 Ensure that the memory regions that are set within the segments correspond to physical contiguous memory regions. Reviewed-by: Simon Horman <horms@verge.net.au> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matthew Leach <matthew.leach@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Ensure that the memory regions that are set within the segments
correspond to physical contiguous memory regions.

Reviewed-by: Simon Horman <horms@verge.net.au>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7539/1: kexec: scan for dtb magic in segments 2012-09-26T21:58:36+00:00 Matthew Leach matthew.leach@arm.com 2012-09-21T17:56:02+00:00 4cabd1d9625c7d88acd143f4021fbef75394f154 This patch allows a dtb to be passed to a new kernel using the kexec mechinism. When loading segments from userspace, scan each segment's first four bytes for the dtb magic. If this is found set the kexec_boot_atags parameter to the relocate_kernel code to the phyical address of this segment. Reviewed-by: Simon Horman <horms@verge.net.au> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matthew Leach <matthew.leach@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
This patch allows a dtb to be passed to a new kernel using the kexec
mechinism.

When loading segments from userspace, scan each segment's first four
bytes for the dtb magic. If this is found set the kexec_boot_atags
parameter to the relocate_kernel code to the phyical address of this
segment.

Reviewed-by: Simon Horman <horms@verge.net.au>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>