[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A35E32C.30609@oracle.com>
Date: Mon, 15 Jun 2009 13:59:08 +0800
From: Tao Ma <tao.ma@...cle.com>
To: Amerigo Wang <xiyou.wangcong@...il.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [Patch BUGFIX] kcore: fix its wrong size on x86_64
Hi Amerigo,
Just patched my kernel and tested.
The bad news is that although the number is changed, but it isn't right
either.
Here is the output.
[root@...t3 ~]# ls -l /proc/kcore
-r-------- 1 root root 131941393240064 Jun 15 13:39 /proc/kcore
But your patch does change something. I just try your commands in
another box which show the right value after reboot. And the result is:
[root@...t8 ~]# ls -l /proc/kcore
-r-------- 1 root root 5301604352 Jun 15 13:35 /proc/kcore
[root@...t8 ~]# readelf -l /proc/kcore
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
0x00000000000008bc 0x0000000000000000 0
LOAD 0x000077ffff601000 0xffffffffff600000 0x0000000000000000
0x0000000000800000 0x0000000000800000 RWE 1000
LOAD 0x000077ffa0001000 0xffffffffa0000000 0x0000000000000000
0x000000005f000000 0x000000005f000000 RWE 1000
LOAD 0x000077ff8200a000 0xffffffff82009000 0x0000000000000000
0x00000000006ceb50 0x00000000006ceb50 RWE 1000
LOAD 0x00003a0000001000 0xffffc20000000000 0x0000000000000000
0x00001fffffffffff 0x00001fffffffffff RWE 1000
LOAD 0x0000000000001000 0xffff880000000000 0x0000000000000000
0x000000013c000000 0x000000013c000000 RWE 1000
[root@...t8 ~]# ls -l /proc/kcore
-r-------- 1 root root 131941393240064 Jun 15 13:35 /proc/kcore
So you see, the second "ls -l" will show the wrong value.
Regards,
Tao
Amerigo Wang wrote:
> On Fri, Jun 12, 2009 at 09:20:50PM -0700, Eric W. Biederman wrote:
>> Amerigo Wang <xiyou.wangcong@...il.com> writes:
>>
>>> Fix wrong /proc/kcore size on x86_64.
>> How does that change anything?
>
> Please check the description below.
>
>>> x86_64 uses __va() macro to caculate the virtual address passed to kclist_add()
>>> but decodes it with its own macro kc_vadd_to_offset(). This is wrong.
>>>
>>> Also, according to Documentation/x86/x86_64/mm.txt, kc_vaddr_to_offset()
>>> is wrong too.
>>>
>>> So just remove them, use the generic macro.
>>>
>>> BTW, the man page for /proc/kcore is wrong, its size can be more than
>>> the physical memory size, because it also contains memory area of
>>> vmalloc(), vsyscall etc...
>> The set of offsets that are usable sure.
>
> We have generic kc_vaddr_to_offset() etc. in fs/proc/kcore.c.
>
>
>> However the size from stat is:
>> proc_root_kcore->size = (size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
>>
>> Which can not be different than the physical memory size.
>
> I never say this is not different, of course they are same, but what Tao
> reported is the wrong size after a read operation, please try the following:
>
> #ls -l /proc/kcore
> #readelf -l /proc/kcore
> #ls -l /proc/kcore
>
> You will find the *second* 'ls -l /proc/kcore' reports a size much more
> than the physical mem size.
>
> And you will notice the difference of it after this patch applied.
>
>
--
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/
Powered by blists - more mailing lists