From nobody Sat Dec 18 06:17:55 2021 X-Original-To: dev-commits-src-all@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 28B2A18E1E57; Sat, 18 Dec 2021 06:18:05 +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 4JGFyh25bZz3qKv; Sat, 18 Dec 2021 06:18:04 +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 1BI6HtVT018378 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 22:17:55 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BI6HtpD018377; Fri, 17 Dec 2021 22:17:55 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 17 Dec 2021 22:17:55 -0800 From: Gleb Smirnoff To: Kristof Provost Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: eb93b99d6986 - main - in_pcb: delay crfree() down into UMA dtor Message-ID: References: <202112051847.1B5Il2GP030287@gitrepo.freebsd.org> <28AE53F1-2B22-444B-B1EC-1600FA741FE2@FreeBSD.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4JGFyh25bZz3qKv 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 [-1.16 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_HAM_MEDIUM(-0.96)[-0.965]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(0.91)[0.905]; 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 Tue, Dec 14, 2021 at 09:58:58PM -0800, Gleb Smirnoff wrote: T> K> For some reason it looks like this commit causes jails to fail to get T> K> fully cleaned up. T> K> I can reproduce that trivially with `cd /usr/tests/sys/net ; kyua test T> K> if_bridge_test:bridge_transmit_ipv4_unicast ; jls -na`. T> K> T> K> Note the jails in dying state. T> K> T> K> The jails created by that test never go away. It’s as if T> K> `crfree(inp->inp_cred);` doesn’t actually get called. And indeed, it T> K> looks like inpcb_dtor() does not get called at all. T> T> Yes, I faced this problem today, too. :( T> T> My radical opinion is that per-VNET pcb zones should just be eliminated. T> The only thing they serve is imposing maxsockets limit separately for T> each VNET. But we already have the maxsocket limit on the socket zone, T> which is _global_! T> T> Anybody to explain me the sense of the per-VNET per-pcb zone limit T> set to the same maxsockets value? You can't create a pcb without a T> socket, which is guaranteed by the in_pcballoc() prototype. Of course T> I understand that pcbs may outlive the socket. But those pcbs that T> outlive a socket, are eventually garbage collected as their lifetime T> is finite. Anyway jail/VNET was never declared as a resource management T> framework anyway! T> T> So, for this particular problem I would suggest just eliminate per-VNET T> pcb zones, but in general the fact that idle SMR zone may never purge T> its cache sucks and needs improvement. I have created a patch that would mitigate that problem. Once the zones are global, the jails will eventually die if there is some pcb zone traffic. https://reviews.freebsd.org/D33542 -- Gleb Smirnoff