Date: Tue, 18 Jan 2022 20:42:43 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: dev-commits-src-main@freebsd.org, current@freebsd.org Cc: bz@freebsd.org, zec@freebsd.org Subject: Re: netinet & netpfil tests failing Message-ID: <YeeWw2mtRGuDzlQp@FreeBSD.org> In-Reply-To: <YeYg71ZNBTpjpVcL@FreeBSD.org> References: <YeYg71ZNBTpjpVcL@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YeeWw2mtRGuDzlQp>