From: "bhe@redhat.com" <bhe@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "holzheu@linux.vnet.ibm.com" <holzheu@linux.vnet.ibm.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH] makedumpfile: Enable --mem-usage for s390x
Date: Tue, 28 Oct 2014 12:46:20 +0800 [thread overview]
Message-ID: <20141028044620.GA15783@dhcp-16-105.nay.redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701D590F8@BPXM01GP.gisp.nec.co.jp>
On 10/28/14 at 04:34am, Atsushi Kumagai wrote:
> >On 10/23/14 at 06:56am, Atsushi Kumagai wrote:
> >> I noticed that is_vmalloc_addr_x86_64() can't be used as is_phys_addr()
> >> due to the "kaslr issue". I fixed it in the common path as below, but
> >> --mem-usage still has the same issue since initial() will be invoked
> >> after get_kcore_dump_loads().
> >>
> >> http://lists.infradead.org/pipermail/kexec/2014-October/012743.html
> >>
> >> I know it's so late, but I began to think the current implementation
> >> that invokes vaddr_to_paddr_XXX() before initial() is bad:
> >>
> >> show_mem_usage()
> >> + get_kcore_dump_loads()
> >> + process_dump_load()
> >> + vaddr_to_paddr_XXX()
> >> + initial()
> >
> >This is a bug. Seems that get_kcore_dump_loads() has to be called in
> >initial(). Since dumped vmcore need contains kernel text segment.
> >Without setting correct value for MODULES_VADDR, it will be equal to
> >__START_KERNEL_map, then calling is_vmalloc_addr() will filter kernel
> >text mapping segment too.
> >
> >Now it seems only one way to solve this, that is moving
> >get_kcore_dump_loads() into initial() just after
> >get_value_for_old_linux() is called.
>
> I agree, I'll do it, thanks.
Actually hpa haven't merged my patchset. Seems he doesn't like current
kaslr design. I am not sure if we have gone too far to adjust
makedumpfile code to support kaslr. I'll ask him for comments or plans.
Thanks
Baoquan
>
>
> Atsushi Kumagai
>
> >> ...
> >>
> >> vaddr_to_paddr_XXX() does VtoP translation *properly*, so it needs
> >> several symbols. This design is OK since it's a general method.
> >> OTOH, we need a kludge which can be used under any situations and
> >> should use it for --mem-usage:
> >>
> >> VtoP_kludge_s390x(unsigned long vaddr)
> >> {
> >> /* s390 has 1:1 VtoP mapping that starts with zero. */
> >> return vaddr;
> >> }
> >>
> >> also x86_64's can be implemented like below:
> >>
> >> VtoP_kludge_x86_64(unsigned long vaddr)
> >> {
> >> /* if the address is direct mapped, it's easy to translate. */
> >> unsigned long paddr = vaddr - PAGE_OFFSET;
> >> return paddr;
> >> }
> >>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2014-10-28 4:48 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 3:15 [PATCH v6 0/8] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-09-01 3:15 ` [PATCH v6 1/8] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
2014-09-01 3:15 ` [PATCH v6 2/8] functions to get crashkernel memory range Baoquan He
2014-09-01 3:15 ` [PATCH v6 3/8] preparation functions for parsing vmcoreinfo Baoquan He
2014-09-01 3:15 ` [PATCH v6 4/8] set vmcoreinfo for kcore Baoquan He
2014-09-01 3:15 ` [PATCH v6 5/8] prepare the dump loads for kcore analysis Baoquan He
2014-09-01 3:15 ` [PATCH v6 6/8] introduce a function exclude_zero_pages_cyclic() Baoquan He
2014-09-01 3:15 ` [PATCH v6 7/8] implement a function to print the memory usage Baoquan He
2014-09-01 3:15 ` [PATCH v6 8/8] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-09-02 11:52 ` Vivek Goyal
2014-09-02 13:15 ` Baoquan He
2014-09-02 13:24 ` Baoquan He
2014-09-03 8:18 ` Atsushi Kumagai
2014-09-03 8:21 ` bhe
2014-09-02 6:20 ` [PATCH v6 0/8] " Atsushi Kumagai
2014-09-02 6:38 ` bhe
2014-09-22 15:02 ` Add "--mem-usage" support for s390x Michael Holzheu
2014-09-23 2:40 ` Baoquan He
2014-09-23 2:48 ` Baoquan He
2014-09-23 2:58 ` Baoquan He
2014-09-24 15:19 ` Michael Holzheu
2014-09-25 9:44 ` Baoquan He
2014-09-26 8:10 ` Michael Holzheu
2014-09-26 8:55 ` Baoquan He
2014-09-26 9:14 ` Baoquan He
2014-09-26 11:34 ` Michael Holzheu
2014-09-29 9:04 ` Baoquan He
2014-09-29 13:12 ` Michael Holzheu
2014-09-29 13:14 ` [PATCH] makedumpfile: Enable --mem-usage " Michael Holzheu
2014-09-30 9:02 ` Baoquan He
2014-10-01 16:59 ` Michael Holzheu
2014-10-09 6:41 ` Atsushi Kumagai
2014-10-10 12:23 ` Michael Holzheu
2014-10-14 7:19 ` Atsushi Kumagai
2014-10-14 7:28 ` bhe
2014-10-14 7:42 ` bhe
2014-10-16 12:37 ` Michael Holzheu
2014-10-23 6:56 ` Atsushi Kumagai
2014-10-23 10:30 ` Michael Holzheu
2014-10-30 1:29 ` Atsushi Kumagai
2014-10-30 9:14 ` Michael Holzheu
2014-10-31 5:25 ` Atsushi Kumagai
2014-10-27 7:57 ` bhe
2014-10-27 9:04 ` bhe
2014-10-28 4:34 ` Atsushi Kumagai
2014-10-28 4:34 ` Atsushi Kumagai
2014-10-28 4:46 ` bhe [this message]
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=20141028044620.GA15783@dhcp-16-105.nay.redhat.com \
--to=bhe@redhat.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox