Hi guys,
On 20/06/18 08:26, Bhupesh Sharma wrote:
> On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang
> <yanjiang.jin@xxxxxxxxxxxxxxxx> 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
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
