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@valinux.co.jp>

--- 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;
+        }

         return addr;
 }
 

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