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?
Cheers,
Daniel
