Re: somewhat reproducable vimage panic

John-Mark Gurney wrote this message on Thu, Jul 23, 2020 at 16:49 -0700:
> Kristof Provost wrote this message on Thu, Jul 23, 2020 at 11:02 +0200:
> > 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.
> 
> I'm testing out this patch now, and let people know how it goes.. It'll
> be nice to not have to worry about these panics..

So far so good...  I am getting these on occasion:
in6_purgeaddr: err=65, destination address delete failed

But that's more that the patch prevented a panic.

The other issue that I'm now seeing is that because we don't forcefully
clear out the multicast task, it can take a good 20+ seconds from the
time a jail is destroyed to the interface appearing again in vnet0.
Pretty sure this is related to the dmesg from above...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."