Re: somewhat reproducable vimage panic

On 23 Jul 2020, at 9:02, Kristof Provost wrote:

> On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote:
>> On 23 Jul 2020, at 8:09, Kristof Provost wrote:
>>
>>> On 23 Jul 2020, at 9:19, Kristof Provost wrote:
>>>> On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
>>>>> So, it's pretty easy to trigger, just attach a couple USB ethernet
>>>>> adapters, in my case, they were ure, but likely any two spare 
>>>>> ethernet
>>>>> interfaces will work, and wire them back to back..
>>>>>
>>>> I’ve been able to trigger it using epair as well:
>>>>
>>>> `sudo sh testinterfaces.txt epair0a epair0b`
>>>>
>>>> I did have to comment out the waitcarrier() check.
>>>>
>>> I’ve done a little bit of digging, and I think I’m starting to 
>>> see how this breaks.
>>>
>>> This always affects the jailed vlan interfaces. They’re getting 
>>> deleted, but the ifp doesn’t go away just yet because it’s still 
>>> in use by the multicast code.
>>> The multicast code does its cleanup in task queues,
>>
>> Wow, did I miss that back then? Did I review a change and not notice? 
>> Sorry if that was the case.
>>
>> Vnet teardown is blocking and forceful.
>> Doing deferred cleanup work isn’t a good idea at all.
>> I think that is the real problem here.
>>
>> I’d rather have us fix this than putting more bandaids into the 
>> code.
>>
> Yeah, agreed. I think hselasky has a better fix: 
> https://reviews.freebsd.org/D24914
>
> I just saw his e-mail in a different thread.

That’ll probably work;  still, the deferred teardown work seems wrong 
to me;  I haven’t investigated;  the patch kind-of says exactly that 
as well: if “wait until deferred stuff is done” is all we are doing, 
why can we not do it on the spot then?

/bz