Re: somewhat reproducable vimage panic

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