Hi Dave,Crash was stopped with following messages when I try to treat very small
dump image.
It was caused in vmalloc_start initialise when vmalloc is not used
(vmlist == 0). This patch return address 0 for this case.> <readmem: c02a99a8, KVADDR, "vmlist", 4, (FOE), afdae5f4>
> <readmem: 0, KVADDR, "first vmlist addr", 4, (ROE), afdae5f0>
> crash: invalid kernel virtual address: 0 type: "first vmlist addr"regards,
--
Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>--- crash-4.0-2.31.orig/memory.c 2006-06-27 23:15:32.000000000 +0900
+++ crash-4.0-2.31/memory.c 2006-07-10 18:24:54.000000000 +0900
@@ -11049,10 +11049,13 @@
ulong vmlist, addr;get_symbol_data("vmlist", sizeof(void *), &vmlist);
-
- if (!readmem(vmlist+OFFSET(vm_struct_addr), KVADDR, &addr,
- sizeof(void *), "first vmlist addr", RETURN_ON_ERROR))
- non_matching_kernel();
+ if (vmlist != 0x0) {
+ if (!readmem(vmlist+OFFSET(vm_struct_addr), KVADDR, &addr,
+ sizeof(void *), "first vmlist addr", RETURN_ON_ERROR))
+ non_matching_kernel();
+ } else {
+ addr = 0;
+ }
Hi Kazuo,
The problem is that the return vmalloc address of zero eventually
gets stored in vt->vmalloc_start, which, among a few other places,
is used here:
#define IS_VMALLOC_ADDR(X) ((ulong)(X) >= vt->vmalloc_start)
Can you verify that setting it to zero will not cause problems in
the macro above, and the other places that it's used directly?
Upon a quick examination, it does looks safe enough in the relevant
vtop routines, but for example, the search command's use of next_kpage()
looks like it might fail.
Perhaps IS_VMALLOC_ADDRESS() itself should also verify
that vt->vmalloc_start is non-zero, and the other places that
use vt->vmalloc_start directly should be verified. (Of course
we don't need to do this kind of check for the processors
that have hardwired vmalloc addresses).
Thanks,
Dave
