Bug #11586


WireGuard panic when saving many times in a row

Added by Jim Pingle 5 months ago. Updated 3 months ago.

Not a Bug
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Moving this over from NG 5538

There is still a lingering panic in WireGuard when saving on an interface, but it's rare.

I have only been able to do this once while I was saving the interface repeatedly when testing some other code.

db:0:kdb.enter.default>  bt
Tracing pid 12 tid 100035 td 0xfffff80005398000
kdb_enter() at kdb_enter+0x37/frame 0xfffffe00400fa120
vpanic() at vpanic+0x197/frame 0xfffffe00400fa170
panic() at panic+0x43/frame 0xfffffe00400fa1d0
trap_fatal() at trap_fatal+0x391/frame 0xfffffe00400fa230
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00400fa280
trap() at trap+0x286/frame 0xfffffe00400fa390
calltrap() at calltrap+0x8/frame 0xfffffe00400fa390
--- trap 0xc, rip = 0xffffffff80d84a27, rsp = 0xfffffe00400fa460, rbp = 0xfffffe00400fa4e0 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0xd7/frame 0xfffffe00400fa4e0
_rm_rlock_hard() at _rm_rlock_hard+0x3c1/frame 0xfffffe00400fa520
wg_route_lookup() at wg_route_lookup+0xdd/frame 0xfffffe00400fa5b0
wg_transmit() at wg_transmit+0x8d/frame 0xfffffe00400fa610
ip_output() at ip_output+0x131c/frame 0xfffffe00400fa750
igmp_intr() at igmp_intr+0x2bc/frame 0xfffffe00400fa830
netisr_dispatch_src() at netisr_dispatch_src+0xca/frame 0xfffffe00400fa880
igmp_fasttimo() at igmp_fasttimo+0x90a/frame 0xfffffe00400fa950
pffasttimo() at pffasttimo+0x54/frame 0xfffffe00400fa980
softclock_call_cc() at softclock_call_cc+0x141/frame 0xfffffe00400faa30
softclock() at softclock+0x79/frame 0xfffffe00400faa50
ithread_loop() at ithread_loop+0x23c/frame 0xfffffe00400faab0
fork_exit() at fork_exit+0x7e/frame 0xfffffe00400faaf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00400faaf0

Low priority and no target since it doesn't appear to be something users could hit often, but we should still take a look.


Actions #1

Updated by Jim Pingle 5 months ago

Parts of the backtrace are similar to #11585 but it's not an exact match.

Actions #2

Updated by Jim Pingle 5 months ago

Textdump from one of the occurences

Actions #3

Updated by Jim Pingle 5 months ago

  • Target version changed from CE-Next to 2.5.1
Actions #4

Updated by Renato Botelho 4 months ago

  • Status changed from New to Feedback

Many wg fixes were cherry-picked from upstream. This must be tested again

Actions #5

Updated by Jim Pingle 4 months ago

  • Target version changed from 2.5.1 to Future
Actions #6

Updated by Christian McDonald 3 months ago

Unable to reproduce this on the latest kmod code..and I've been quite aggressive at building and tearing down tunnels in quick succession over the course of several weeks. No kernel panics yet.

Actions #7

Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to Not a Bug
Actions #8

Updated by Jim Pingle 3 months ago

  • Target version deleted (Future)

Also available in: Atom PDF