somewhat reproducable vimage panic
John-Mark Gurney
jmg at funkthat.com
Wed Jul 22 19:35:06 UTC 2020
John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 -0700:
> Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:
> > Is this related to
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985> and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326>
>
> Definitely not 234985.. I'm using ue interfaces, and so they don't
> get destroyed while the jail is going away...
>
> I don't think it's 238326 either. This is 100% reliable and it's in
> the IP multicast code.. It looks like in_multi isn't holding an
> interface or address lock waiting for things to free up...
Did a little more poking, and it looks like the vnet is free'd before
the ifnet is free'd causing this problem:
(kgdb) print inm->inm_ifp[0].if_refcount
$5 = 1
(kgdb) print inm->inm_ifp[0].if_vnet[0]
$6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de},
vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054,
vnet_sockcnt = 3735929054, vnet_state = 3735929054,
vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = 16045693110842147038,
vnet_shutdown = 222}
So the multicast code is fine, it holds and releases a reference to
ifnet..
The issue is that the reference to the ifnet doesn't involve a
reference to the vnet/prison.
I have noticed that a number of times after a jail destroy that one
of my interfaces doesn't make it back to the main OS.. it's just gone..
I can "make" it reappear by reseting the hardware, but that does imply
that an ifnet is hanging out in limbo...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-net
mailing list