Messages in this thread | | | Date | Tue, 16 Jun 2009 01:01:32 +0800 | From | Tao Ma <> | Subject | Re: [Patch BUGFIX] kcore: fix its wrong size on x86_64 |
| |
ebiederm@xmission.com wrote: > TaoMa <tao.ma@oracle.com> writes: > >> ebiederm@xmission.com wrote: >>> Tao Ma <tao.ma@oracle.com> writes: >>> >>> >>>> Hi Amerigo, >>>> >>>> The wrong number I mean is 131941393240064. >>>> >>>> So do you think >>>> [root@test3 ~]# ls -l /proc/kcore >>>> -r-------- 1 root root 131941393240064 Jun 15 13:39 /proc/kcore >>>> >>>> is better than >>>> >>>> [taoma@test2 ~]$ ll /proc/kcore >>>> -r-------- 1 root root 281474974617600 Jun 15 15:20 /proc/kcore >>>> ? >>>> >>>> I don't think so. >>>> >>>> Actually the right result should look like >>>> >>>> [root@test8 ~]# ls -l /proc/kcore >>>> -r-------- 1 root root 5301604352 Jun 15 13:35 /proc/kcore >>>> >>>> And with your patch I can't get this number. >>>> >>> Actually that value is the bug. It has absolutely nothing >>> to do with the offsets that are valid within /proc/kcore. >>> >>> Why do you prefer the smaller number? >>> >> Amerigo said in the previous e-mail that " 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..." >> >> I have 4G memory, and 5301604352 is just a bit larger than 4G and looks sane. So >> I misunderstand that this number is right. > > It should also include the 32 Tebibyte range we have for vmalloc. So > a completely dense encoding would be a bit larger than 35184372088832 > bytes. You can see that range in your readelf -l output. > > Since the encoding is not dense the size actually comes to. 256TiB. > Or roughly 281474976710656 bytes. > >> But if it is also a bug, I am willing to test any of the new patch. ;) > > Not in the sense that anything could go wrong. Merely in the sense that > we have a contradictory definition. Which causes loads of confusion. > > I am wondering if this difference in definition has caused any > problems applications to fail or if this just started out as an > observation of an anomaly? I first noticed it when my el5 box refused to start kdump service and kexec said something like "Can't find kernel text map area from kcore". And then I found this number which looked a bit strange. I also just have another x86 box and "ls -l /proc/kcore" shows: -r-------- 1 root root 939528192 Jun 16 10:01 /proc/kcore So I thought this may be a bug and started this thread.
Anyway, later I found that kexec's problem isn't related to this issue. So maybe we can leave as-is.
regards, Tao
| |