On 22 Jul 2020, at 19:34, John-Mark Gurney wrote:
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.
Does it need to? The ifnet cannot go away while something holds a
reference to it, right?
Sounds more like the teardown order is wrong (again)?
There should be no more multicast when IP etc. is gone. That means MC
doesn’t properly cleanup itself.
I guess I should go back now and re-read your original problem statement
on how you trigger this..
/bz
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
