From nobody Wed Jan 19 04:42:43 2022 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 183FD1962648; Wed, 19 Jan 2022 04:42:53 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdtL412fGz3rfV; Wed, 19 Jan 2022 04:42:52 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20J4giPE093655 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 Jan 2022 20:42:44 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20J4ghhl093654; Tue, 18 Jan 2022 20:42:43 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 18 Jan 2022 20:42:43 -0800 From: Gleb Smirnoff 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: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JdtL412fGz3rfV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [0.87 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.97)[0.965]; MLMMJ_DEST(0.00)[dev-commits-src-main,current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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