I have a system with a loopback kernel module installed. Through a bunch of routing and iptable rules, packets coming out of the loopback interface are sent over an ipsec tunnel. I am seeing that under load, the kernel panics or dumps a lot of messages that say "BUG: soft lockup - CPU#0 stuck for X secs".
The stack trace is always in an encryption function like crypto_cbc_encrypt or des3_ede_encrypt. There is a lot of traffic going over the ipsec tunnels and the system is spending lot of time in encryption+decryption.
My concern is that it is always CPU 0. How do I ensure that other CPUs are also sharing the crypto load. I have seen sometimes when the ksoftirq0 thread is at 100%. Again it is always cpu0. This is mostly happening when packets are being forward from the loopback interface, go through the xfrm rules and into the tunnels.
How do I also check the CPU mask for the loopback kernel module? Is there such a thing?
/proc/cryptocontain (after using IPsec for a bit: algorithms may be loaded on demand)? I'd be more concerned about the bug than about the CPU balance at this stage. There is no CPU mask for kernel threads AFAIK. – Gilles May 29 '14 at 23:02