Amerigo Wang <xiyou.wangcong@xxxxxxxxx> writes:--
On Mon, Jun 08, 2009 at 09:10:10PM -0700, Eric W. Biederman wrote:AmÃrico Wang <xiyou.wangcong@xxxxxxxxx> writes:Hello, Eric.
On Mon, Jun 8, 2009 at 4:00 PM, Tao Ma<tao.ma@xxxxxxxxxx> wrote:Short of some strange patch applied I would guess that a non-sense /proc/kcoreReally weird...yes. the same box and the same linux version.But the result is the sameYes?
Your printk() shows kcore size is: 5301604352, and in your subject it is
281474974617600...
Or they happened in the same time?
A bit strange.
[taoma@ocfs2-test2 ~]$ dmesg|grep "high memory"
high memory ffff88013c000000, size 5301604352
[taoma@ocfs2-test2 ~]$ ll /proc/kcore
-r-------- 1 root root 281474974617600 Jun 8 15:20 /proc/kcore
They should be the same. This means we have some problem in our procfs.
And, we have no problem on i386, I, myself, even can't reproduce this on my
x86_64 box...
Drop Cc to x86 people, add some Cc to proc people. :)
Eric, Alexey, any ideas?
Tao, would you like to send us your .config? Thanks.
size is related to a kernel memory stomp, stepping on the high_memory variable.
I see the problem now, I think the documentation of /proc/kcore
is wrong, the size of kcore can be more than the size of physical
memory, because it also contains the info of kernel modules which
stay above the mapping of phy memory, see arch/x86/mm/init_64.c.
What do you think?
I think that doesn't make any sense.
I was reading the code.
I smell a nasty problem somewhere.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/