Re: git: eb93b99d6986 - main - in_pcb: delay crfree() down into UMA dtor

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