net: mitigate vnet / epair cleanup races

There's a race where dying vnets move their interfaces back to their original
vnet, and if_epair cleanup (where deleting one interface also deletes the other
end of the epair). This is commonly triggered by the pf tests, but also by
cleanup of vnet jails.

As we've not yet been able to fix the root cause of the issue work around the
panic by not dereferencing a NULL softc in epair_qflush() and by not
re-attaching DYING interfaces.

This isn't a full fix, but makes a very common panic far less likely.

PR:		244703, 238870
Reviewed by:	lutz_donnerhacke.de
MFC after:	4 days
Differential Revision:	https://reviews.freebsd.org/D26324

sys/net/if.c

@@ -1298,6 +1298,11 @@ if_vmove(struct ifnet *ifp, struct vnet *new_vnet)
 	ifindex_free_locked(ifp->if_index);
 	IFNET_WUNLOCK();
 
+
+	/* Don't re-attach DYING interfaces. */
+	if (ifp->if_flags & IFF_DYING)
+		return (0);
+
 	/*
 	 * Perform interface-specific reassignment tasks, if provided by
 	 * the driver.

sys/net/if_epair.c

@@ -611,8 +611,14 @@ epair_qflush(struct ifnet *ifp)
 	struct epair_softc *sc;
 
 	sc = ifp->if_softc;
-	KASSERT(sc != NULL, ("%s: ifp=%p, epair_softc gone? sc=%p\n",
-	    __func__, ifp, sc));
+
+	/*
+	 * See epair_clone_destroy(), we can end up getting called twice.
+	 * Don't do anything on the second call.
+	 */
+	if (sc == NULL)
+		return;
+
 	/*
 	 * Remove this ifp from all backpointer lists. The interface will not
 	 * usable for flushing anyway nor should it have anything to flush