[Crash-utility] x86 remap allocator in kernel 3.0

[David Mair]

Hi Dave,

On 01/12/2012 12:58 PM, Dave Anderson wrote:
>
>
> ----- Original Message -----
>> On 01/11/2012 06:53 AM, Petr Tesarik wrote:
>>> Dne Út 10. ledna 2012 19:23:24 Petr Tesarik napsal(a):
>>>> Dne Út 10. ledna 2012 19:14:32 Petr Tesarik napsal(a):
>> ... [ cut ] ...
>>>> crash>   vtop f2800080
>>>> VIRTUAL   PHYSICAL
>>>> f2800080  1fde00080
>>>>
>>>> PAGE DIRECTORY: c08ed000
>>>>     PGD: c08ed018 =>   8ea001
>>>>     PMD:   8eaca0 =>   80000001fde001e3
>>>>    PAGE: 1fde00000  (2MB)
>>>>
>>>>         PTE         PHYSICAL   FLAGS
>>>> 80000001fde001e3  1fde00000
>>>>   (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL|NX)
>>>>
>>>>     PAGE     PHYSICAL   MAPPING    INDEX CNT FLAGS
>>>
>>> BTW the data from struct page is really missing here. I traced this down to an
>>> integer overflow in dump_memory_nodes():
>> ... [ cut ] ...
>>> David (Mair), could you address this, as already discussed in private mails,
>>> please?
>>
>> The attached patch fixes this for me.
>
> Hmmm, not so much for me...
>
> When I test the patch on RHEL5, RHEL6 and Fedora x86 kernels, the
> command always fails like this:
>
> crash>  kmem -n
> NODE    SIZE    PGLIST_DATA   BOOTMEM_DATA   NODE_ZONES
>    0    262075     c0a3a680      c0aa5ce8      c0a3a680
>                                                c0a3b1c0
>                                                c0a3bd00
>                                                c0a3c840
> MEM_MAP      START_PADDR    START_MAPNR
> Segmentation fault
> $
>
> I haven't look into it, and this is probably not related:
>
> cc -c -g -DX86 -m32 -D_FILE_OFFSET_BITS=64 -DGDB_7_3_1  memory.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
> memory.c: In function 'dump_memory_nodes':
> memory.c:13410: warning: cast to pointer from integer of different size
> memory.c:13199: warning: 'node_start_paddr' may be used uninitialized in this function
>
> But from under gdb:
>
> crash>  kmem -n
> [Detaching after fork from child process 16870.]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0809cd94 in mkstring (s=0xffe8a8bc "  c0a3a680  ", size=16, flags=133, opt=0x1000<Address 0x1000 out of bounds>)
>      at tools.c:1620
> 1620                    sprintf(s, "%llx", *((ulonglong *)opt));
> (gdb) bt
> #0  0x0809cd94 in mkstring (s=0xffe8a8bc "  c0a3a680  ", size=16, flags=133, opt=0x1000<Address 0x1000 out of bounds>)
>      at tools.c:1620
> #1  0x080b1ad7 in dump_memory_nodes (initialize=0) at memory.c:13406
> #2  0x080d46cc in cmd_kmem () at memory.c:4221
> #3  0x080941b8 in exec_command () at main.c:751
> #4  0x08093fe6 in main_loop () at main.c:699
> #5  0x081db622 in current_interp_command_loop ()
> #6  0x081dbf01 in captured_command_loop ()
> #7  0x081db0a4 in catch_errors ()
> #8  0x081dce07 in captured_main ()
> #9  0x081db0a4 in catch_errors ()
> #10 0x081dce49 in gdb_main ()
> #11 0x081dce99 in gdb_main_entry ()
> #12 0x08116668 in gdb_main_loop (argc=2, argv=0xffe8d494) at gdb_interface.c:75
> #13 0x08093ce0 in main (argc=3, argv=0xffe8d494) at main.c:603
> (gdb) p opt
> $1 = 0x1000<Address 0x1000 out of bounds>
> (gdb)
>
> I thought it might be just an x86 issue, but it also fails
> the same way on RHEL5, RHEL6 and Fedora x86_64 kernels.

I'm looking into it, that's the change I made to the fprintf() that uses 
node_start_paddr. The patch would be a fix for the problem Petr reported 
if it did not include the expansion to 64-bits in the fprintf() that's 
the whole last piece of the patch. The fix is pretty obvious now to the 
original patch:

LONGLONG_HEX takes a ulonglong *
LONG_HEX takes a ulong

Changing the last modified MKSTR() to take &node_start_paddr should 
resolve it. Patch attached.

-- 
David.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand-node_start_addr.patch
Type: text/x-patch
Size: 2849 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120112/cfc01550/attachment.bin>