[Crash-utility] Re: [PATCH] IA-64 4-level page table support

Hi Troy, While running a few tests on a RHEL3 ia64 box, I noticed that the new "ps -a" function was failing to access user space stack addresses. As it turns out, it was a regression in the ia64 4-level page table support put into 4.0-3.1. The 3-level ia64_vtop() function was working for most user addresses, and for kernel vmalloc addresses, by dumb luck, but user stack addresses failed due to the use of an incorrect PGDIR_SHIFT value. In your patch, you indicate this: #define PGDIR_SHIFT_4L (PUD_SHIFT + (PTRS_PER_PTD_SHIFT)) #define PGDIR_SHIFT_3L (PMD_SHIFT + (PTRS_PER_PTD_SHIFT)) /* Turns out 4L & 3L PGDIR_SHIFT are the same (for now) */ #define PGDIR_SHIFT PGDIR_SHIFT_4L But PGDIR_SHIFT_3L is 36 and PGDIR_SHIFT_4L is 47. And in the 3-level ia64_vtop() function, PGDIR_SHIFT was being used. By changing ia64_vtop() to use PGDIR_SHIFT_3L instead, all translations work. FWIW, the problem only manifested itself with user space addresses in the last two vm areas, which have bits set in the address space affected by the shift value: crash> vm PID: 1 TASK: e000004040200000 CPU: 0 COMMAND: "init" MM PGD RSS TOTAL_VM e00000409ef47b00 e00000404579c000 1168k 2960k VMA START END FLAGS FILE e00000409ef3f8b8 0 4000 84011 e00000409ef3fe08 2000000000000000 2000000000038000 875 /lib/ld-2.3.2.so e00000409ef3fe90 2000000000038000 2000000000040000 100877 /lib/ld-2.3.2.so e00000409ef3f830 200000000005c000 20000000002a4000 75 /lib/tls/libc-2.3.2.so e00000409ef3fad8 20000000002a4000 20000000002ac000 70 /lib/tls/libc-2.3.2.so e00000409ef3f9c8 20000000002ac000 20000000002b8000 100077 /lib/tls/libc-2.3.2.so e00000409ef3f940 20000000002b8000 20000000002c4000 100077 e00000409ef3fd80 4000000000000000 4000000000010000 1875 /sbin/init e00000409ef3fc70 600000000000c000 6000000000010000 101877 /sbin/init e00000409ef3fa50 6000000000010000 6000000000034000 100073 e00000409ef3fcf8 60000fff80000000 60000fff80004000 233 e00000409ef3ff18 60000fffffff8000 60000fffffffc000 100177 ...so the incorrect use of 47 worked by mistake for the other user space and vmalloc addresses. It's always something... ;-) Thanks, Dave