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

Reply via email to