Re: What's going on with vnets and epairs w/ addresses?

  Zhenlei, Bjoern, Mark,

sorry for delayed response on this thread. Back when the problem
was first introduced, I made a code that forces purge of SMR zones.
However, I didn't push it in, hence the change on the test suite side
to remove interfaces from inside the jail before destroying it was
sufficient to close all leaks associated with the test suite.

I just rebased the code to fresh main and put it here:

https://github.com/glebius/FreeBSD/tree/smr-purge

The proof of concept based on the test from Zhenlei looks like this:

#!/bin/sh
n="test_ref_leak"

jail -c name=$n path=/ vnet persist
# The following line trigger jail pr_ref leak
jexec $n ifconfig lo0 inet 127.0.0.1/8

jail -R $n

for zone in tcp_inpcb udp_inpcb; do
        sysctl vm.uma_zone_reclaim=${zone}
done

jls -j $n

At the point of the call to jls(8) the jail no longer exists.

My opinion on the whole problem matches Mark's opinion, that he expressed
in his email on December 20.  I like the idea of doing the prison
checks at a later stage of inpcb lookup, especially given new discoveries
on the performance impact by Drew.  The proper fix may take a while.

In addition to that I have strong opinion against the way we move interfaces
between the jails. I claim that if did it right (tm), the problem we are
talking about won't exist even with all the existing layering violations
between inpcb+smr and jails+epoch. I will write a longer email on what I
believe is the right (tm) way to manage interfaces/devices within jails.
We already have had discussions on that with Alexander melifaro@ and Warner
imp@.  However, proper implementation will take a while.

We may use code from my smr-purge branch as a temporary solution. Any
thoughts on that?

-- 
Gleb Smirnoff