On Wed, Oct 04, 2023 at 09:13:59PM +0200, Alexander Bluhm wrote: > On Wed, Oct 04, 2023 at 08:42:48PM +0200, Kirill Miazine wrote: > > > If it happns again, could you send an 'ps axlww | grep ifconifg' > > > output? Then we see the wait channel where it hangs in the kernel. > > > > > > $ ps axlww > > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME > > > COMMAND > > > > Here it happened again: > > > > 0 75339 23922 0 10 0 360 296 wg_ifq D+U p0 0:00.00 > > ifconfig wg1 destroy > > wg_peer_destroy() > ... > NET_LOCK(); > while (!ifq_empty(&sc->sc_if.if_snd)) { > NET_UNLOCK(); > tsleep_nsec(sc, PWAIT, "wg_ifq", 1000); > NET_LOCK(); > } > NET_UNLOCK(); > > This net lock dance looks fishy. And the sleep has a timeout of 1 > milli second. But that is may be per packet. So if you have a > long queue or the queue refills somehow, it will take forever. > > I think the difference in the usage is constant traffic that keeps > the send queue full. The timeout hides the problem when there are > only a few packets. >
This should ensure wg_qstart() will not dereference dying `peer'. Looks crappy and potentially could block forever, but should work. However netlock it unnecessary here. netlocked wg_output() could fill `if_snd' while netlock released before tsleep(), so it serializes nothing but stops packets processing. Kirill, does this diff help? Index: sys/net/if_wg.c =================================================================== RCS file: /cvs/src/sys/net/if_wg.c,v retrieving revision 1.31 diff -u -p -r1.31 if_wg.c --- sys/net/if_wg.c 26 Sep 2023 15:16:44 -0000 1.31 +++ sys/net/if_wg.c 4 Oct 2023 20:01:16 -0000 @@ -507,13 +507,8 @@ wg_peer_destroy(struct wg_peer *peer) noise_remote_clear(&peer->p_remote); - NET_LOCK(); - while (!ifq_empty(&sc->sc_if.if_snd)) { - NET_UNLOCK(); + while (!ifq_empty(&sc->sc_if.if_snd)) tsleep_nsec(sc, PWAIT, "wg_ifq", 1000); - NET_LOCK(); - } - NET_UNLOCK(); taskq_barrier(wg_crypt_taskq); taskq_barrier(net_tq(sc->sc_if.if_index));