A new vmcore core analysis to get the correct parameter address
The Call trace is as below.
[261687.768385] task: ffff881ff2e9b800 ti: ffff881ff2eb0000 task.ti: ffff881ff2eb0000
[261687.768390] RIP: 0010:[<ffffffff8161a554>] [<ffffffff8161a554>] neigh_timer_handler+0x184/0x290
[261687.768392] RSP: 0018:ffff881fffa43e18 EFLAGS: 00010246
[261687.768393] RAX: 0000000000000001 RBX: ffff881fb3b0cc00 RCX: 0000000000000000
[261687.768394] RDX: 000000010f9445b4 RSI: ffffffff8161a3d0 RDI: ffff881fb3b0cc28
[261687.768395] RBP: ffff881fffa43e28 R08: 000000000001ab40 R09: dead000000000200
[261687.768396] R10: ffffffff815fb944 R11: 00000000000001c4 R12: 0000000000000000
[261687.768398] R13: ffff881fb3b0cc58 R14: 0000000000000000 R15: ffff881fb3b0cc00
[261687.768400] FS: 0000000000000000(0000) GS:ffff881fffa40000(0000) knlGS:0000000000000000
[261687.768401] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[261687.768402] CR2: 000000000000006c CR3: 0000000001ab6000 CR4: 00000000001406e0
[261687.768403] Stack:
[261687.768407] 0000000000000100 ffffffff8161a3d0 ffff881fffa43e68 ffffffff810ee547
[261687.768409] ffff881fffa43e58 ffff881fffa4eac0 ffff881fb3b0cc58 ffff881fffa43ea8
[261687.768412] 0000000000000000 ffff881fffa4faf8 ffff881fffa43ee8 ffffffff810ee860
[261687.768412] Call Trace:
[261687.768419] <IRQ>
[261687.768419] [<ffffffff8161a3d0>] ? neigh_delete+0x190/0x190
[261687.768425] [<ffffffff810ee547>] call_timer_fn+0x47/0x160
[261687.768428] [<ffffffff810ee860>] run_timer_softirq+0x200/0x380
[261687.768431] [<ffffffff8161a3d0>] ? neigh_delete+0x190/0x190
[261687.768437] [<ffffffff8108b01a>] __do_softirq+0x10a/0x350
[261687.768440] [<ffffffff8108b3d5>] irq_exit+0x125/0x130
[261687.768445] [<ffffffff8105be24>] ? native_apic_msr_eoi_write+0x14/0x20
[261687.768453] [<ffffffff816ec8a6>] smp_apic_timer_interrupt+0x46/0x60
[261687.768457] [<ffffffff816ea43e>] apic_timer_interrupt+0x6e/0x80
[261687.768467] <EOI>
[261687.768467] [<ffffffff815b86c5>] ? cpuidle_enter_state+0xc5/0x230
[261687.768470] [<ffffffff815b8695>] ? cpuidle_enter_state+0x95/0x230
[261687.768474] [<ffffffff815b8847>] cpuidle_enter+0x17/0x20
[261687.768480] [<ffffffff810ca664>] cpuidle_idle_call+0xe4/0x1e0
[261687.768483] [<ffffffff810ca955>] cpu_idle_loop+0x1f5/0x220
[261687.768486] [<ffffffff810ca99b>] ? cpu_startup_entry+0x1b/0x70
[261687.768488] [<ffffffff810ca9df>] cpu_startup_entry+0x5f/0x70
[261687.768492] [<ffffffff810530db>] start_secondary+0xbb/0xc0
[261687.768518] Code: d3 5f ad ff 85 c0 74 2f 0f b6 93 b5 00 00 00 83 e2 11 85 d2 0f 84 2d ff ff ff 48 89 df e8 f5 de ff ff e9 24 ff ff ff 48 8b 4b 10 <48> 63 71 6c 48 01 d6 e9 ba fe ff ff f0 ff 43 30 eb cb 66 2e 0f
[261687.768521] RIP [<ffffffff8161a554>] neigh_timer_handler+0x184/0x290
[261687.768522] RSP <ffff881fffa43e18>
[261687.768523] CR2: 000000000000006c
And from the vmcore, if we use RDI:ffff881fb3b0cc28 as the address of struct neighbour.
crash7lates> whatis neigh_timer_handler
void neigh_timer_handler(unsigned long);
crash7lates> struct neighbour ffff881fb3b0cc28
struct neighbour {
next = 0xff,
tbl = 0x2,
parms = 0xffff883feb8f8600,
confirmed = 18446612406849209856,
updated = 1,
lock = {
It is not correct since tbl is 0x2. tbl is the pointer of struct neigh_table.
From vmcore,
"
net/core/neighbour.c: 920
0xffffffff8161a550 <neigh_timer_handler+384>: mov 0x10(%rbx),%rcx
0xffffffff8161a554 <neigh_timer_handler+388>: movslq 0x6c(%rcx),%rsi
"
crash7lates> struct neighbour -o
struct neighbour {
[0] struct neighbour *next;
[8] struct neigh_table *tbl;
[16] struct neigh_parms *parms; <---this is the parms.
"
next = now + NEIGH_VAR(neigh->parms, RETRANS_TIME);
"
neigh->parms is struct neighour address + 0x10.
%rbx is the struct neighbour address.
crash7lates> struct neighbour ffff881fb3b0cc00
struct neighbour {
next = 0x0,
tbl = 0xffffffff81bd7e40 <arp_tbl>,
parms = 0x0,
confirmed = 4556281706,
updated = 4556341706,
Now it is correct.
In short, sometimes the address in RDI is not the correct address of the first parameter.
We should analyze the source code and vmcore to get the correct address.