> On 25 Aug 2021, at 20:35, Daniel Jakots <[email protected]> wrote: > > On Wed, 25 Aug 2021 12:40:29 +0300, Vitaliy Makkoveev <[email protected]> > wrote: > >> I see this assertion wrong. if_get(9) returns NULL here if the >> interface is going to die and already unlinked from the stack, but >> the routing table entries are not yet removed by in{,6}_ifdetach(). >> So I propose to return ESRCH and let concurrent if_detach() to follow >> it's way. >> >> Also the following "ifp != NULL" assertions in rtm_output() are wrong >> and kernel lock serialization doesn't work here because we are >> grabbing netlock before if_get(9). We have the same case here: the >> returned NULL means the requested interface is going to die and there >> is no reason to perform ifp->if_rtrequest(). > > Thanks for looking into it! > >> Does the diff below helps? The panic should gone, but I'm interesting >> about the routing table consistency. > > What should I look for with the diff? If the routing table is free of > wg0 route after the destroy? >
Yes, all wg0 related entries should gone. You caught the race condition between "ifconfig wg0 destroy" and something which removes wg0 related entry from routing table, and that’s the reason I'm interesting.
