Re: git: fec8a8c7cbe4 - main - inpcb: use global UMA zones for protocols

On Mon, Jan 03, 2022 at 06:22:59PM +0000, Gleb Smirnoff wrote:
T> The branch main has been updated by glebius:
T> 
T> URL: https://cgit.FreeBSD.org/src/commit/?id=fec8a8c7cbe4384c7e61d376f3aa5be5ac895915
T> 
T> commit fec8a8c7cbe4384c7e61d376f3aa5be5ac895915
T> Author:     Gleb Smirnoff <glebius@FreeBSD.org>
T> AuthorDate: 2022-01-03 18:15:22 +0000
T> Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
T> CommitDate: 2022-01-03 18:17:46 +0000
T> 
T>     inpcb: use global UMA zones for protocols
T>     
T>     Provide structure inpcbstorage, that holds zones and lock names for
T>     a protocol.  Initialize it with global protocol init using macro
T>     INPCBSTORAGE_DEFINE().  Then, at VNET protocol init supply it as
T>     the main argument to the in_pcbinfo_init().  Each VNET pcbinfo uses
T>     its private hash, but they all use same zone to allocate and SMR
T>     section to synchronize.
T>     
T>     Note: there is kern.ipc.maxsockets sysctl, which controls UMA limit
T>     on the socket zone, which was always global.  Historically same
T>     maxsockets value is applied also to every PCB zone.  Important fact:
T>     you can't create a pcb without a socket!  A pcb may outlive its socket,
T>     however.  Given that there are multiple protocols, and only one socket
T>     zone, the per pcb zone limits seem to have little value.  Under very
T>     special conditions it may trigger a little bit earlier than socket zone
T>     limit, but in most setups the socket zone limit will be triggered
T>     earlier.  When VIMAGE was added to the kernel PCB zones became per-VNET.
T>     This magnified existing disbalance further: now we have multiple pcb
T>     zones in multiple vnets limited to maxsockets, but every pcb requires a
T>     socket allocated from the global zone also limited by maxsockets.
T>     IMHO, this per pcb zone limit doesn't bring any value, so this patch
T>     drops it.  If anybody explains value of this limit, it can be restored
T>     very easy - just 2 lines change to in_pcbstorage_init().
T>     
T>     Differential revision:  https://reviews.freebsd.org/D33542

This commit fired several tests failing:

https://ci.freebsd.org/job/FreeBSD-main-amd64-test/20277/

What happens here is that scapy would emit WARNINGs when it sees an
interface without address. For example:

>ifconfig epair create
>python3.8 -c 'import scapy.all'
WARNING: No IPv4 address found on epair7a !
WARNING: No IPv4 address found on epair7b !
WARNING: more No IPv4 address found on epair7a !

That would trigger atf failures, despite test case returns success.

So, the real failure is not in the tests reported by job 20277,
but in the previous ones, that leave orphaned epair interfaces.

This is also associated with delayed jail destroy due to delayed
memory reclamation in the pcb zone due to SMR.

I'm working on the test suite to run clean.

-- 
Gleb Smirnoff