[PATCH] arm64/mm: Introduce a variable to hold base address of linear region

James Morse james.morse at arm.com
Wed Jun 20 03:06:33 PDT 2018


Hi guys,

On 20/06/18 08:26, Bhupesh Sharma wrote:
> On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang
> <yanjiang.jin at hxt-semitech.com> wrote:
>> If /proc/kcore always exists in kexec/kdump, I think this issue can be fixed
>> easily. But it requires  that Kexec/kdump have to rely on " CONFIG_PROC_KCORE=y".
>> I am not sure if we can persuade Kexec-tools community to accept this.

For the kernel this would be:
--------------%<--------------
diff --git a/arch/Kconfig b/arch/Kconfig
index 1aa59063f1fd..0ea2c7c0ac08 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -8,6 +8,7 @@ config CRASH_CORE

 config KEXEC_CORE
        select CRASH_CORE
+       select PROC_KCORE
        bool

 config HAVE_IMA_KEXEC
--------------%<--------------

With this kernel's that support kdump but don't have /proc/kcore wouldn't have
the new PT_NOTEs anyway. Whatever you do today is all you can do.


> Most distributions like Ubuntu and Fedora already enable
> CONFIG_PROC_KCORE by default, to support user-space tools like
> crash-utility and makedumpfile which can be used for 'live' debugging
> of a primary kernel (without the requirement of being in the secondary
> or crash kernel).
> 
> For such cases. '/proc/kcore' and 'vmlinux' are the only available
> sources for PT_NOTE/PT_LOAD segments and kernel symbols respectively.
> 
> Since we need to support all such existing user-space utilities (which
> work well with other archs like x86 and ppc64),

x86 has kaslr too, I couldn't work out how your user-space:phys_to_virt() works
there. Are we missing an alternative trick?


> we need to have a
> solution which works without modifying most of them - the rest (like
> kexec-tools) can be easily modified to follow the same approach.

(We're  also trying to solve this in a way that lets user-space shed
arch-specific code.)


Thanks,

James



More information about the kexec mailing list