https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235097
--- Comment #14 from Andrey V. Elsukov <a...@freebsd.org> ---
(In reply to Kristof Provost from comment #12)
> The following appears to fix the panic in comment #6:
>
> diff --git a/sys/net/if.c b/sys/net/if.c
> index a6552f80f37..7e3e662d342 100644
> --- a/sys/net/if.c
> +++ b/sys/net/if.c
> @@ -1194,6 +1195,11 @@ if_detach_internal(struct ifnet *ifp, int vmove,
> struct if_clone **ifcp)
> if (!CK_STAILQ_EMPTY(&ifp->if_addrhead)) {
> ifa = CK_STAILQ_FIRST(&ifp->if_addrhead);
> CK_STAILQ_REMOVE(&ifp->if_addrhead, ifa, ifaddr,
> ifa_link);
> + //KASSERT(ifa != ifp->if_addr, (""));
> + if (ifa == ifp->if_addr) {
> + ifp->if_addr = NULL;
> + printf("KP: set ifp->if_addr to NULL\n");
> + }
> IF_ADDR_WUNLOCK(ifp);
> ifa_free(ifa);
> } else
>
> We free the ifaddr, but we can still have a pointer to it in ifp->if_addr.
> This check triggers, and in several test runs with this patch I've not
> managed to reproduce the panic any more. I'm doing more runs, because this
> problem comes and goes, but I hope this will be a useful pointer to someone
> who knows that code better than me.
ifa_free() does not free the memory immediately, so it is safe to make access
to ifp->if_addr while you are in NET_EPOCH() section.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
