Hi folks,
On 5/16/18 10:20 AM, Martin Pieuchot wrote:
On 16/05/18(Wed) 08:06, Harald Dunkel wrote:
Hi folks,
Thanks for the report.
hopefully its allowed to repost this message here:
One gateway running 6.3 ran into the debugger last night. Last words:
login: kernel: protection fault trap, code=0
Stopped at export_sa+0x5c: movl 0(%rcx),%ecx
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
export_sa(10,ffff800033445e70) at export_sa+0x5c
pfkeyv2_expire(ffff8000013d4c00,ffff8000013d4c00) at pfkeyv2_expire+0x14e
tdb_timeout(ffff800033446020) at tdb_timeout+0x39
softclock_thread(0) at softclock_thread+0xc6
end trace frame: 0x0, count: -4
ddb{0}> show registers
rdi 0xffff800033445e98
rsi 0xffff8000013d4c00
rbp 0xffff800033445e70
rbx 0xffff800033445e98
rdx 0xffffffff81abdff0 cpu_info_full_primary+0x1ff0
rcx 0xdeadbeefdeadbeef
^^^^^^^^^^^^^^^^^^
That means that the TDB has already been freed. This is possible
because the timeout sleeps on the NET_LOCK(). Diff below should prevent
that by introducing a tdb_reaper() function like we do in other parts of
the stack.
Is it possible that this problem was introduced by syspatch 008_ipsecout ?
Regards
Harri
