Re: What's going on with vnets and epairs w/ addresses?

From: Zhenlei Huang <>
Date: Tue, 03 Jan 2023 00:59:33 UTC

Happy New Year 2023!

> On Dec 27, 2022, at 4:42 AM, Gleb Smirnoff <> wrote:
> Zhenlei, Bjoern, Mark,
> sorry for delayed response on this thread. Back when the problem
> was first introduced, I made a code that forces purge of SMR zones.
> However, I didn't push it in, hence the change on the test suite side
> to remove interfaces from inside the jail before destroying it was
> sufficient to close all leaks associated with the test suite.
> I just rebased the code to fresh main and put it here:
> The proof of concept based on the test from Zhenlei looks like this:
> #!/bin/sh
> n="test_ref_leak"
> jail -c name=$n path=/ vnet persist
> # The following line trigger jail pr_ref leak
> jexec $n ifconfig lo0 inet
> jail -R $n
> for zone in tcp_inpcb udp_inpcb; do
>       sysctl vm.uma_zone_reclaim=${zone}
> done
> jls -j $n
> At the point of the call to jls(8) the jail no longer exists.
> My opinion on the whole problem matches Mark's opinion, that he expressed
> in his email on December 20.  I like the idea of doing the prison
> checks at a later stage of inpcb lookup, especially given new discoveries
> on the performance impact by Drew.  The proper fix may take a while.
> In addition to that I have strong opinion against the way we move interfaces
> between the jails. I claim that if did it right (tm), the problem we are
> talking about won't exist even with all the existing layering violations
> between inpcb+smr and jails+epoch. I will write a longer email on what I
> believe is the right (tm) way to manage interfaces/devices within jails.
> We already have had discussions on that with Alexander melifaro@ and Warner
> imp@.  However, proper implementation will take a while.
> We may use code from my smr-purge branch as a temporary solution. Any
> thoughts on that?

The code in smr-purge branch should also apply to non-vnet jails.
I think it is OK as a temporary solution.

> -- 
> Gleb Smirnoff