From: Baoquan He <bhe@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: panand@redhat.com, keescook@chromium.org,
ats-kumagai@wm.jp.nec.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
takahiro.akashi@linaro.org, mingo@redhat.com,
anderson@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
tglx@linutronix.de, thgarnie@google.com, tonli@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Tue, 1 Nov 2016 13:33:53 +0800 [thread overview]
Message-ID: <20161101053353.GC20838@x1> (raw)
In-Reply-To: <20161101051019.GB4625@dhcp-128-65.nay.redhat.com>
On 11/01/16 at 01:10pm, Dave Young wrote:
> On 10/06/16 at 04:46pm, Baoquan He wrote:
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > utility, mainly makedumpfile can use them to identify the base of each
> > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > struct number_table in makedumpfile to import data easily.
> >
> > Since they are related to x86_64 only, put them into
> > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > together since it's also for x86_64 only.
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > arch/x86/kernel/machine_kexec_64.c | 4 ++++
> > kernel/kexec_core.c | 3 ---
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> > index 5a294e4..e150dd7 100644
> > --- a/arch/x86/kernel/machine_kexec_64.c
> > +++ b/arch/x86/kernel/machine_kexec_64.c
> > @@ -337,6 +337,10 @@ void arch_crash_save_vmcoreinfo(void)
> > #endif
> > vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
> > kaslr_offset());
> > + VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> > + VMCOREINFO_NUMBER(PAGE_OFFSET);
> > + VMCOREINFO_NUMBER(VMALLOC_START);
> > + VMCOREINFO_NUMBER(VMEMMAP_START);
>
> Pratyush has posted makedumpfile patches below to avoid the VMCOREINFO:
> http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
>
> But we have this in mainline which also introduced the VMCOREINFO
> numbers, can you send a patch to revert them?
OK, will do.
However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
still needed. I checked code, seems no better way to avoid. I am not
sure how many people are really using "-e" option to exclude unused
vmemmap pages.
Maybe just leave it as is, and fix it when people complain?
> commit 0549a3c02efb350776bc869685a361045efd3a29
> Author: Thomas Garnier <thgarnie@google.com>
> Date: Tue Oct 11 13:55:08 2016 -0700
>
> kdump, vmcoreinfo: report memory sections virtual addresses
> [snip]]
>
> > }
> >
> > /* arch-dependent functionality related to kexec file-based syscall */
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index 5616755..8ad3a29e 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1467,9 +1467,6 @@ static int __init crash_save_vmcoreinfo_init(void)
> > #endif
> > VMCOREINFO_NUMBER(PG_head_mask);
> > VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
> > -#ifdef CONFIG_X86
> > - VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> > -#endif
>
> Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
> I remember Dave Anderson said he use it in crash utility, cced him.
>
> > #ifdef CONFIG_HUGETLB_PAGE
> > VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
> > #endif
> > --
> > 2.5.5
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
keescook@chromium.org, ats-kumagai@wm.jp.nec.com,
thgarnie@google.com, takahiro.akashi@linaro.org,
mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
tglx@linutronix.de, akpm@linux-foundation.org, tonli@redhat.com,
anderson@redhat.com, panand@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Tue, 1 Nov 2016 13:33:53 +0800 [thread overview]
Message-ID: <20161101053353.GC20838@x1> (raw)
In-Reply-To: <20161101051019.GB4625@dhcp-128-65.nay.redhat.com>
On 11/01/16 at 01:10pm, Dave Young wrote:
> On 10/06/16 at 04:46pm, Baoquan He wrote:
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > utility, mainly makedumpfile can use them to identify the base of each
> > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > struct number_table in makedumpfile to import data easily.
> >
> > Since they are related to x86_64 only, put them into
> > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > together since it's also for x86_64 only.
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > arch/x86/kernel/machine_kexec_64.c | 4 ++++
> > kernel/kexec_core.c | 3 ---
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> > index 5a294e4..e150dd7 100644
> > --- a/arch/x86/kernel/machine_kexec_64.c
> > +++ b/arch/x86/kernel/machine_kexec_64.c
> > @@ -337,6 +337,10 @@ void arch_crash_save_vmcoreinfo(void)
> > #endif
> > vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
> > kaslr_offset());
> > + VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> > + VMCOREINFO_NUMBER(PAGE_OFFSET);
> > + VMCOREINFO_NUMBER(VMALLOC_START);
> > + VMCOREINFO_NUMBER(VMEMMAP_START);
>
> Pratyush has posted makedumpfile patches below to avoid the VMCOREINFO:
> http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
>
> But we have this in mainline which also introduced the VMCOREINFO
> numbers, can you send a patch to revert them?
OK, will do.
However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
still needed. I checked code, seems no better way to avoid. I am not
sure how many people are really using "-e" option to exclude unused
vmemmap pages.
Maybe just leave it as is, and fix it when people complain?
> commit 0549a3c02efb350776bc869685a361045efd3a29
> Author: Thomas Garnier <thgarnie@google.com>
> Date: Tue Oct 11 13:55:08 2016 -0700
>
> kdump, vmcoreinfo: report memory sections virtual addresses
> [snip]]
>
> > }
> >
> > /* arch-dependent functionality related to kexec file-based syscall */
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index 5616755..8ad3a29e 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1467,9 +1467,6 @@ static int __init crash_save_vmcoreinfo_init(void)
> > #endif
> > VMCOREINFO_NUMBER(PG_head_mask);
> > VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
> > -#ifdef CONFIG_X86
> > - VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> > -#endif
>
> Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
> I remember Dave Anderson said he use it in crash utility, cced him.
>
> > #ifdef CONFIG_HUGETLB_PAGE
> > VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
> > #endif
> > --
> > 2.5.5
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
next prev parent reply other threads:[~2016-11-01 5:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 8:46 [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo Baoquan He
2016-10-06 8:46 ` Baoquan He
2016-10-06 20:07 ` Eric W. Biederman
2016-10-06 20:07 ` Eric W. Biederman
2016-10-11 7:41 ` Baoquan He
2016-10-11 7:41 ` Baoquan He
2016-10-11 8:19 ` Dave Young
2016-10-11 8:19 ` Dave Young
2016-10-11 8:43 ` Dave Young
2016-10-11 8:43 ` Dave Young
2016-10-12 0:26 ` Baoquan He
2016-10-12 0:26 ` Baoquan He
2016-10-12 9:09 ` Pratyush Anand
2016-10-12 9:09 ` Pratyush Anand
2016-10-13 8:53 ` Baoquan He
2016-10-13 8:53 ` Baoquan He
2016-10-14 3:13 ` Dave Young
2016-10-14 3:13 ` Dave Young
2016-11-01 5:10 ` Dave Young
2016-11-01 5:10 ` Dave Young
2016-11-01 5:33 ` Baoquan He [this message]
2016-11-01 5:33 ` Baoquan He
2016-11-01 14:13 ` Dave Anderson
2016-11-01 14:13 ` Dave Anderson
2016-11-02 1:34 ` Baoquan He
2016-11-02 1:34 ` Baoquan He
2016-11-02 13:29 ` Dave Anderson
2016-11-02 13:29 ` Dave Anderson
2016-11-02 13:48 ` Baoquan He
2016-11-02 13:48 ` Baoquan He
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=20161101053353.GC20838@x1 \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anderson@redhat.com \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=panand@redhat.com \
--cc=takahiro.akashi@linaro.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=tonli@redhat.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.