From: Dave Anderson <anderson@redhat.com>
To: Baoquan He <bhe@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 <takahiro.akashi@linaro.org>,
mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
tglx@linutronix.de, Dave Young <dyoung@redhat.com>,
thgarnie@google.com, tonli@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Tue, 1 Nov 2016 10:13:34 -0400 (EDT) [thread overview]
Message-ID: <115590076.11735656.1478009614692.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20161101053353.GC20838@x1>
----- Original Message -----
> 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?
Speaking of complaints, is there any chance you can make the
x86_64 "phys_base" value available? The VMCOREINFO_SYMBOL(phys_base)
is useless since its contents are needed in order to access the
symbol address.
Dave
>
> > 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: Dave Anderson <anderson@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
keescook@chromium.org, ats-kumagai@wm.jp.nec.com,
thgarnie@google.com, takahiro akashi <takahiro.akashi@linaro.org>,
mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
tglx@linutronix.de, akpm@linux-foundation.org, tonli@redhat.com,
panand@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Tue, 1 Nov 2016 10:13:34 -0400 (EDT) [thread overview]
Message-ID: <115590076.11735656.1478009614692.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20161101053353.GC20838@x1>
----- Original Message -----
> 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?
Speaking of complaints, is there any chance you can make the
x86_64 "phys_base" value available? The VMCOREINFO_SYMBOL(phys_base)
is useless since its contents are needed in order to access the
symbol address.
Dave
>
> > 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 14:14 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
2016-11-01 5:33 ` Baoquan He
2016-11-01 14:13 ` Dave Anderson [this message]
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=115590076.11735656.1478009614692.JavaMail.zimbra@redhat.com \
--to=anderson@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=bhe@redhat.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.