On Thu, 9 Oct 2014 06:41:10 +0000
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:
> Hello,
>
> >On Tue, 30 Sep 2014 17:02:01 +0800
> >Baoquan He <bhe at redhat.com> wrote:
> >
> >> On 09/29/14 at 03:14pm, Michael Holzheu wrote:
> >> > Implement is_vmalloc_addr() using /proc/iommem parsing to enable the new
> >> > makedumpfile option "--mem-usage".
> >> >
> >> > Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> >>
> >>
> >> Hi Michael,
> >>
> >> This idea looks good to me. One question, should it be put in
> >> arch/s390.c since this is only for s390? Then iomem_for_each_line() need
> >> be declared in makedumpfile.h .
> >>
> >> If later it's needed by other arch, can be taken out to makedumpfile.c,
> >> that should be better. Surely this is only my personal concern, if
> >> Atsushi like to accept it, I am fine too.
> >
> >Hello Atsushi,
> >
> >What is your preference regarding this question?
> >
> >Michael
>
> In the first place, this is_vmalloc_addr() for s390 isn't a good
> implementation because it works only on 1st kernel due to the
> dependence on /proc/iomem. is_vmalloc_addr_XXX() are general functions,
> they can be called from any path besides --mem-usage.
>
> I think the Michael's first idea below is better since it implements
> is_real_addr() only for --mem-usage as a common function for all
> architectures, it's explicit design.
>
> >@@ -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_real_addr(p->virt_start))
> > continue;
> > loads++;
> > }
>
> However, this code will not work since the argument of is_real_addr()
> must be physical address. Even unluckily, /proc/kcore's PT_LOAD looks
> useless for VtoP converting because PhysAddr is always 0:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x00000000000002a8 0x0000000000000000 0x0000000000000000
> 0x0000000000000a84 0x0000000000000000 0
> LOAD 0x00007fffff601000 0xffffffffff600000 0x0000000000000000
> 0x0000000000001000 0x0000000000001000 RWE 1000
> LOAD 0x00007fff81001000 0xffffffff81000000 0x0000000000000000
> 0x0000000000a1b000 0x0000000000a1b000 RWE 1000
> LOAD 0x0000490000001000 0xffffc90000000000 0x0000000000000000
> 0x00001fffffffffff 0x00001fffffffffff RWE 1000
> LOAD 0x00007fffa0001000 0xffffffffa0000000 0x0000000000000000
> 0x000000005f000000 0x000000005f000000 RWE 1000
> ...
>
>
> So the way using /proc/iomem seems inappropriate, we have to consider other
> approaches (but I still don't have any good ideas...)
Hello Atsushi,
Hmmm ok, sure. For x86 using /proc/iomem does not work because there is no 1:1
mapping for the kernel address space. The kernel/real memory is mapped somewhere
at the end, right?
For s390 we have a 1:1 mapping for the kernel physical memory that starts with
zero. Therefore IMHO we could use /proc/iomem. For example, on my s390x system
with 1GB memory and 256MB crashkernel:
$ cat /proc/iomem
00000000-2fffffff : System RAM
00000000-007ddd4b : Kernel code
007ddd4c-00bfcc5f : Kernel data
00e18000-01c28b1f : Kernel bss
30000000-3fffffff : Crash kernel
$ objdump -h /proc/kcore
...
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000158 0x0000000000000000 0x0000000000000000
0x00000000000027fc 0x0000000000000000 0
LOAD 0x000003e080003000 0x000003e080000000 0x0000000000000000
0x0000001f00000000 0x0000001f00000000 RWE 1000
LOAD 0x000003ff80003000 0x000003ff80000000 0x0000000000000000
0x0000000080000000 0x0000000080000000 RWE 1000
LOAD 0x0000000000003000 0x0000000000000000 0x0000000000000000
0x0000000030000000 0x0000000030000000 RWE 1000
LOAD 0x000003d100003000 0x000003d100000000 0x0000000000000000
0x0000000000c00000 0x0000000000c00000 RWE 1000
So in that case every /proc/kcore load that is below 0x30000000 must
be real memory.
Michael
