https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241106
Zhenlei Huang <z...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Open |Closed
CC| |z...@freebsd.org
Resolution|--- |Overcome By Events
--- Comment #7 from Zhenlei Huang <z...@freebsd.org> ---
(In reply to lenzi.sergio from comment #4)
> system panics on rtsock.c for the reason that rt->rt_ifp->if_addr have a null
> pointer.
> It is not clear the reason rt->rt_ifp->if_addr have a null pointer but when
> try to access rt->rt_ifp->if_addr->ifa_addr near line 1578 of rtsock.c the
> system panics...
I'm recently reviewing the attaching progress of net interfaces ( if_attach()
), and the link-layer address `ifp->if_addr` is initialized and will never be
NULL, even after the interface been detached ( then ifp->if_addr may point to
freed memory, if not within the net epoch section ).
> I also insert code of RTSOCK_LOCK/RTSOCK_UNLOCK on any ioctl call, and since
> than,
> the system does not panic any more..
> A more study must be done where/why rt->rt_ifp->if_addr comes NULL, and in
> that
> case the colunm Netif from the command: netstat -4rn either shows ""
> (nothing)
> or "---". when this happens, the system panics some minutes later...
The "" or "---" name of the interface drive me to presume that the route entry
is actually referring to previously freed interface, probably tun1 in your
case.
Since the introduction of scalable route multipath [1] in stable/13,
`sysctl_dumpentry()` was heavily rewrote, so I'm closing this. 12.4 has reached
its EoL.
[1]
https://cgit.freebsd.org/src/commit/?id=fedeb08b6a58e708e1153224d37ad26bdc1062a2
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
