Re: [Crash-utility] - creeping schizophrenia?
Piet Delaney wrote:
Dave Anderson wrote:
>
> In the "heading-down-a-slippery-slope" department, I've hacked
> up a version of crash that is capable of dealing with the
> relocatable x86 FC7/upstream kernels, whose kernel symbol values
> in the vmlinux file do not match up with their counterparts
> when the kernel is actually loaded.
>
> In the "vmlinux and /dev/crash do not match" FC7/upstream
> scenario, the kernel gets compiled with:
Why use /dev/crash instead of /proc/kcore? Wouldn't it be
more symmetric to gdb and crash to rely on /proc/kcore
shifting the reading/writing of the memory and for the
kgdb stab to take care of it for live kernels? KDUMP
would also use kcore compatible format. I tried crash
on a /proc/kcore file and it didn't work. Seemed wrong
to me.
There are a few reasons...
/proc/kcore suffers the same problem as /dev/mem in that
there's no way to access physical memory above highmem
on the x86 (896MB / 0x3800000). Here are the Program
Headers contents from a /proc/kcore on a 1GB system:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000094 0x00000000 0x00000000 0x00698 0x00000 0
LOAD 0x38801000 0xf8800000 0x00000000 0x6ffe000 0x6ffe000 RWE 0x1000
LOAD 0x001000 0xc0000000 0x00000000 0x38000000 0x38000000 RWE 0x1000
It only describes the kernel's 896MB unity-mapped virtual
region from 0xc0000000 to 0xf8000000, plus the vmalloc
range starting at 0xf8800000. So when access to physical
memory above that is required, crash commands fail.
I originally did allow /proc/kcore usage back in the '90's,
but back then x86 systems with more than 1GB were pretty rare.
And then I became a Red Hat employee...
With respect to /proc/kcore, RHEL3 and RHEL4 kernels have this:
static int open_kcore(struct inode * inode, struct file * filp)
{
return -EPERM;
}
And although RHEL5 kernels opened up /proc/kcore for kdump,
it only allows access to the ELF header:
# ls -l /proc/kcore
-r-------- 1 root root 4096 Jul 25 09:11 /proc/kcore
#
With resplect to /dev/mem, x86 and x86_64 RHEL kernels
only allow access to the first 256 pages of RAM:
int devmem_is_allowed(unsigned long pagenr)
{
if (pagenr <= 256)
return 1;
if (!page_is_ram(pagenr))
return 1;
return 0;
}
Hence the need for /dev/crash in x86 and x86_64 RHEL
kernels.
Outside of Red Hat, you can use /dev/mem, but again, on
x86 machines, it won't allow access to physical memory
above highmem, so commands may fail.
Dave
Feels like creeping *schizophrenia.
-piet