Date: Wed, 15 Dec 2021 10:47:42 +0100 From: Kristof Provost <kp@FreeBSD.org> To: Gleb Smirnoff <glebius@freebsd.org> 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: <D85D47CD-1D03-43E7-84A4-579AF48A29E5@FreeBSD.org> In-Reply-To: <YbmEIsjf7RZBOOAJ@FreeBSD.org> References: <202112051847.1B5Il2GP030287@gitrepo.freebsd.org> <28AE53F1-2B22-444B-B1EC-1600FA741FE2@FreeBSD.org> <YbmEIsjf7RZBOOAJ@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Dec 2021, at 6:58, Gleb Smirnoff wrote: > 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 ge= t > K> fully cleaned up. > K> I can reproduce that trivially with `cd /usr/tests/sys/net ; kyua te= st > 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=E2=80=99s as if > K> `crfree(inp->inp_cred);` doesn=E2=80=99t actually get called. And in= deed, 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= =2E > 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! > rctl(8) does appear to support per-jail resource limits, but I=E2=80=99m = not sure how complete or functional that is. I don=E2=80=99t really have any strong feelings either way. > 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. > Yeah, that=E2=80=99s certainly going to need some love at some point. Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D85D47CD-1D03-43E7-84A4-579AF48A29E5>