linux-kernel - [PATCH 0/4] kcore: cleanup and fix bahavior to find physcal memory range v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090722140613.0a751811.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Wed, 22 Jul 2009 14:06:13 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: [PATCH 0/4] kcore: cleanup and fix bahavior to find physcal memory
 range v2

I'm sorry I can't find who should be in CC.

This includes some amounts changes to arch-specici code, 
but very special codes for kcore. Can I test this in -mm if no objections ?

Now, /proc/kcore 's physical memory information is set up at boot
via kclist_add(). But it's not updated at memory hotplug etc and
it can include much memory holes. This patch is for generatinc /proc/kcore
based on memory management information maintained by the kernel.

 For usual archs, /proc/iomem is used
 For ppc, lmb information will be used.

This is v2. bugs/bahavior is fixed. Below is output of
"readelf -l /proc/kcore" before/after the patch. (on my vm host..)


=====[Before]======
Elf file type is CORE (Core file)
Entry point 0x0
There are 6 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                 0x00000000000021a4 0x0000000000000000         0
  LOAD           0x00007fffff603000 0xffffffffff600000 0x0000000000000000
                 0x0000000000800000 0x0000000000800000  RWE    1000
  LOAD           0x00007fffa0003000 0xffffffffa0000000 0x0000000000000000
                 0x000000005f000000 0x000000005f000000  RWE    1000
  LOAD           0x00007fff8100c000 0xffffffff81009000 0x0000000000000000
                 0x000000000111a000 0x000000000111a000  RWE    1000
  LOAD           0x0000490000003000 0xffffc90000000000 0x0000000000000000
                 0x00001fffffffffff 0x00001fffffffffff  RWE    1000
  LOAD           0x0000080000003000 0xffff880000000000 0x0000000000000000
                 0x0000000065400000 0x0000000065400000  RWE    1000

====[After]=====


Elf file type is CORE (Core file)
Entry point 0x0
There are 8 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000200 0x0000000000000000 0x0000000000000000
                 0x00000000000021a4 0x0000000000000000         0
  LOAD           0x0000080065303000 0xffff880065300000 0x0000000000000000
                 0x0000000000100000 0x0000000000100000  RWE    1000
  LOAD           0x0000080000103000 0xffff880000100000 0x0000000000000000
                 0x00000000651f0000 0x00000000651f0000  RWE    1000
  LOAD           0x0000080000013000 0xffff880000010000 0x0000000000000000
                 0x000000000008f000 0x000000000008f000  RWE    1000
  LOAD           0x0000490000003000 0xffffc90000000000 0x0000000000000000
                 0x00001fffffffffff 0x00001fffffffffff  RWE    1000
  LOAD           0x00007fff8100c000 0xffffffff81009000 0x0000000000000000
                 0x000000000111a000 0x000000000111a000  RWE    1000
  LOAD           0x00007fffa0003000 0xffffffffa0000000 0x0000000000000000
                 0x000000005f000000 0x000000005f000000  RWE    1000
  LOAD           0x00007fffff603000 0xffffffffff600000 0x0000000000000000
                 0x0000000000800000 0x0000000000800000  RWE    1000



You can see the section

    LOAD         0x0000080000003000 0xffff880000000000 0x0000000000000000
                 0x0000000065400000 0x0000000065400000  RWE    1000
is divided into

  LOAD           0x0000080065303000 0xffff880065300000 0x0000000000000000
                 0x0000000000100000 0x0000000000100000  RWE    1000
  LOAD           0x0000080000103000 0xffff880000100000 0x0000000000000000
                 0x00000000651f0000 0x00000000651f0000  RWE    1000
  LOAD           0x0000080000013000 0xffff880000010000 0x0000000000000000
                 0x000000000008f000 0x000000000008f000  RWE    1000

This is on physical memory information.

And yes, this host's memory map is following. 
(This is same to /proc/iomem, of course)
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x000652f0
[    0.000000]     0: 0x00065300 -> 0x00065400


Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/