From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"bhe@redhat.com" <bhe@redhat.com>
Subject: Re: [PATCH] makedumpfile: Enable --mem-usage for s390x
Date: Thu, 23 Oct 2014 12:30:07 +0200 [thread overview]
Message-ID: <20141023123007.282cb52e@holzheu> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701D580A9@BPXM01GP.gisp.nec.co.jp>
Hello Atsushi,
On Thu, 23 Oct 2014 06:56:47 +0000
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
> >On Tue, 14 Oct 2014 07:19:13 +0000
> >Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:
[snip]
> 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()
> ...
> vaddr_to_paddr_XXX() does VtoP translation *properly*, so it needs
> several symbols. This design is OK since it's a general method.
So the current implementation that uses vaddr_to_paddr_xxx()
for --mem-usage *before* initial() is broken? Or does it currently
works only by chance?
> 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;
> }
What about using the kernel name __pa(vaddr)?
[snip]
> >--- a/elf_info.c
> >+++ b/elf_info.c
> >@@ -854,7 +854,7 @@ int get_kcore_dump_loads(void)
> >
> > for (i = 0; i < num_pt_loads; ++i) {
> > struct pt_load_segment *p = &pt_loads[i];
> >- if (is_vmalloc_addr(p->virt_start))
> >+ if (!is_phys_addr(p->virt_start))
>
> This part implicitly does VtoP translation.
> Actually it works for s390x but it's not suitable as a general code,
> so we should use VtoP_kludge(should be better name!) too.
> Then we can use is_iomem_phys_addr() also for other architecture.
So how exactly should the code look like for non s390x architectures?
Michael
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-10-23 10:30 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 [this message]
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
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=20141023123007.282cb52e@holzheu \
--to=holzheu@linux.vnet.ibm.com \
--cc=bhe@redhat.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