‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, January 10, 2019 11:52 PM, Qian Cai <c...@lca.pw> wrote:
> 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? console=ttyS0 root=/dev/sda debug earlyprintk=serial slub_debug=QUZ
