On 1/10/19 10:15 PM, Esme wrote:
>>> [ 75.793150] RIP: 0010:rb_insert_color+0x189/0x1480
>>
>> What's in that line? Try,
>>
>> $ ./scripts/faddr2line vmlinux rb_insert_color+0x189/0x1480
>
> rb_insert_color+0x189/0x1480:
> __rb_insert at /home/files/git/linux/lib/rbtree.c:131
> (inlined by) rb_insert_color at /home/files/git/linux/lib/rbtree.c:452
>
gparent = rb_red_parent(parent);
tmp = gparent->rb_right; <-- GFP triggered here.
It suggests gparent is NULL. Looks like it misses a check there because parent
is the top node.
>>
>> What's steps to reproduce this?
>
> The steps is the kernel config provided (proc.config) and I double checked
> the attached C code from the qemu image (attached here). If the kernel does
> not immediately crash, a ^C will cause the fault to be noticed. The report
> from earlier is the report from the same code, my assumption was that the
> possible pool/redzone corruption is making it a bit tricky to pin down.
>
> If you would like alternative kernel settings please let me know, I can do
> that, also, my current test-bench has about 256 core's on x64, 64 of them are
> bare metal and 32 are arm64. Any possible preferred configuration tweaks I'm
> all ears, I'll be including some of these steps you suggested to me in
> any/additional upcoming threads (Thank you for that so far and future
> suggestions).
>
> Also, there is some occasionally varying stacks depending on the corruption,
> so this stack just now (another execution of test3.c);
I am unable to reproduce any of those here. What's is the output of
/proc/cmdline in your guest when this happens?
