Re: netinet & netpfil tests failing

On Mon, Jan 17, 2022 at 06:07:43PM -0800, Gleb Smirnoff wrote:
T> * Reclaim the memory from pcb zone(s), when jail is destroyed, returning back
T>   the old behaviour that with test suites 'jail -r' is always synchronous.
T>   Some prerequisites for this approach are here: https://reviews.freebsd.org/D33868
T> * Protect jails with epoch, bypass the cred pointer in inpcb and in the lookup
T>   check inp->inp_prison->pr_foo. After that the crfree() can be moved back to the
T>   immediate inpcb free procedure.  Mark has a quick & dirty proof of concept for
T>   this approach.
T> * In the test suite destroy the interface from the jail:
T>   'jexec jname ifconfig ${ifname} destroy'.
T> 
T> I'd like to add a few words on the last option.  To me it seems most elegant as we
T> are improving the test suite instead of changing kernel to meet demands of the suite.
T> However, it doesn't work :( Why? Why does 'jexec jname ifconfig epair0b destroy' or
T> 'jexec jname ifconfig lo1 destroy' returns ENXIO? Because the interface was created
T> within vnet0 and is linked on vnet0 cloner's list. To repeat: epair0b ifnet is linked
T> to the jail's list of network interfaces, but it linked on vnet0 list of epair(4)
T> ifcloner.  Likewise, some lo4 interface would also be in the jail list of interfaces,
T> but on vnet0 if_loop cloner.  This makes it impossible to destroy such interface from
T> inside the jail.  Neither it is possible to destroy it from the outside, for obvious
T> reasons.  There are more side effects about this.  For example the only reason why we
T> can't create an interface with the same name inside a jail using its cloner list is
T> call to ifunit() in the beginning of if_clone_createif().  This definitely is a part
T> of design, since if_clone_create()/if_clone_destroy() would lookup vnet0 cloner list
T> in case if interface is not found on the current vnet list.
T> 
T> To put it short, it is yet another problem created by if_vmove :( Not an easy one
T> to fix and makes the third approach to the problem complicated.

Looking more into the problem, I've found pieces of code that confirm that the clone
behavior of staying at home vnet cloner when vmoved is known and seems to be part of
design. I created a patch to better workaround this fact and be able to properly
destroy a once vmove'd clone:

https://reviews.freebsd.org/D33942

Followed by earlier suggested change to the test suite:

https://reviews.freebsd.org/D33943

With these two patches in place I have all of the test suite fixed. Waiting for
your reviews to push them in.

-- 
Gleb Smirnoff