Subject: Re: kernels > v4.12 oops/crash with ipsec-traffic: bisected to b838d5e1c5b6e57b10ec8af2268824041e3ea911: ipv4: mark DST_NOGC and remove the operation of dst_free()

From: Wolfgang Walter <[email-masked]>
Date: Fri, 07 Sep 2018 22:22:39 +0200

Am Freitag, 31. August 2018, 08:50:24 schrieb Steffen Klassert:
> On Thu, Aug 30, 2018 at 08:53:50PM +0200, Wolfgang Walter wrote:
> > Hello,
> > 
> > kernels > 4.12 do not work on one of our main routers. They crash as soon
> > as ipsec-tunnels are configured and ipsec-traffic actually flows.
> 
> Can you please send the backtrace of this crash?
> 

I bootet the b838d5e1c5b6e57b10ec8af2268824041e3ea911 several times but I 
could not record the complete trace. I think I have to log to the serial 
console but I can't do that before next week.

What I could record ist:

There is a always 
	<IRQ> ... </IRQ>
the callrace.

This is the part I could see:

irq_exit+0x71/0x80
do_IRQ+0x4d/0xd0
common_interrup+07a/0x7a
</IRQ>
RIP: 010:cpuidle_enter_state+0x11d/0x200
RSP: 0018:ffffc9000321bee0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffffc4
RAX: ffff88085efde450 RBX: 0000000000000004 RCX: 00000003c9e63c13
RDX: 00000003c9e63c13 RSI: ffb03103fe35ac43 RDI: 0000000000000000
RBP: ffffe8ffff7cf600 R08: 000000000000000c R09: 0000000000000004
R10: 0000000000000400 R11: 00000003c99e56fc R12: 00000003c9e63c13
R13: 00000003c9da9567 R14: 0000000000000004 R15: ffffffff822763e0
do_idle+0xd3/0x160
cpu_startup_entry+0x14/0x20
secondary_startup_64+0xa5/0xb0
Code: 00 0f b7 83 c0 00 00 00 80 7c 02 08 01 0f 86 d3 02 00 00 41
8b 8c 24 3c 10 00 00 48 8b 6b 58 85 c9 0f 84 2f 01 00 00 48 83 e5 fe <f6> 45 
60
02 0f 84 4e 01 00 00 f6 43 38 01 74 0d 80 00 bd ab 00 00
RIP: ip_forward+0xd4/0x470 RSP: ffff88085efc3cb0
CR2: 0000000000000060
----[ end trace 7205b53c25b7b35a ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
Rebooting in 60 seconds..

I got an email from Tobias Hommel and I think it is the same problem.

It is very clear that it is the difference from

	ipv4: call dst_hold_safe() properly

to

	ipv4: mark DST_NOGC and remove the operation of dst_free()

which triggers this bug.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts