From nobody Wed Dec 15 05:58:58 2021 X-Original-To: dev-commits-src-main@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 B604C18F339E; Wed, 15 Dec 2021 05:59:00 +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 4JDPh43LdCz3h7w; Wed, 15 Dec 2021 05:59:00 +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 1BF5wwHn001412 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 21:58:58 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BF5wwBL001411; Tue, 14 Dec 2021 21:58:58 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2021 21:58:58 -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 the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <28AE53F1-2B22-444B-B1EC-1600FA741FE2@FreeBSD.org> X-Rspamd-Queue-Id: 4JDPh43LdCz3h7w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 10:42:49PM +0100, Kristof Provost wrote: K> > in_pcb: delay crfree() down into UMA dtor K> > K> > inpcb lookups, which check inp_cred, work with pcbs that K> > potentially went K> > through in_pcbfree(). So inp_cred should stay valid until SMR K> > guarantees K> > its invisibility to lookups. K> > K> > While here, put the whole inpcb destruction sequence of K> > in_pcbfree(), K> > inpcb_dtor() and inpcb_fini() sequentially. K> > K> > Submitted by: markj K> > Differential revision: https://reviews.freebsd.org/D33273 K> K> For some reason it looks like this commit causes jails to fail to get K> fully cleaned up. K> I can reproduce that trivially with `cd /usr/tests/sys/net ; kyua test K> if_bridge_test:bridge_transmit_ipv4_unicast ; jls -na`. K> K> Note the jails in dying state. K> K> The jails created by that test never go away. It’s as if K> `crfree(inp->inp_cred);` doesn’t actually get called. And indeed, it K> looks like inpcb_dtor() does not get called at all. Yes, I faced this problem today, too. :( My radical opinion is that per-VNET pcb zones should just be eliminated. The only thing they serve is imposing maxsockets limit separately for each VNET. But we already have the maxsocket limit on the socket zone, which is _global_! Anybody to explain me the sense of the per-VNET per-pcb zone limit set to the same maxsockets value? You can't create a pcb without a socket, which is guaranteed by the in_pcballoc() prototype. Of course I understand that pcbs may outlive the socket. But those pcbs that outlive a socket, are eventually garbage collected as their lifetime is finite. Anyway jail/VNET was never declared as a resource management framework anyway! So, for this particular problem I would suggest just eliminate per-VNET pcb zones, but in general the fact that idle SMR zone may never purge its cache sucks and needs improvement. -- Gleb Smirnoff