On Sat, Dec 17, 2022 at 11:22 AM Gleb Smirnoff <gleb...@freebsd.org> wrote: > > Zhenlei, > > On Fri, Dec 16, 2022 at 06:30:57PM +0800, Zhenlei Huang wrote: > Z> I managed to repeat this issue on CURRENT/14 with this small snip: > Z> > Z> ------------------------------------------- > Z> #!/bin/sh > Z> > Z> # test jail name > Z> n="test_ref_leak" > Z> > Z> jail -c name=$n path=/ vnet persist > Z> # The following line trigger jail pr_ref leak > Z> jexec $n ifconfig lo0 inet 127.0.0.1/8 > Z> > Z> jail -R $n > Z> > Z> # wait a moment > Z> sleep 1 > Z> > Z> jls -j $n > Z> > Z> After DDB debugging and tracing , it seems that is triggered by a combine > of [1] and [2] > Z> > Z> [1] https://reviews.freebsd.org/rGfec8a8c7cbe4384c7e61d376f3aa5be5ac895915 > <https://reviews.freebsd.org/rGfec8a8c7cbe4384c7e61d376f3aa5be5ac895915> > Z> [2] https://reviews.freebsd.org/rGeb93b99d698674e3b1cc7139fda98e2b175b8c5b > <https://reviews.freebsd.org/rGeb93b99d698674e3b1cc7139fda98e2b175b8c5b> > Z> > Z> > Z> In [1] the per-VNET uma zone is shared with the global one. > Z> `pcbinfo->ipi_zone = pcbstor->ips_zone;` > Z> > Z> In [2] unref `inp->inp_cred` is deferred called in inpcb_dtor() by > uma_zfree_smr() . > Z> > Z> Unfortunately inps freed by uma_zfree_smr() are cached and inpcb_dtor() is > not called immediately , > Z> thus leaking `inp->inp_cred` ref and hence `prison->pr_ref`. > Z> > Z> And it is also not possible to free up the cache by per-VNET SYSUNINIT > tcp_destroy / udp_destroy / rip_destroy. > > This is known issue and I'd prefer not to call it a problem. The "leak" of a > jail > happens only if machine is idle wrt the networking activity. > > Getting back to the problem that started this thread - the epair(4)s not > immediately > popping back to prison0. IMHO, the problem again lies in the design of > if_vmove and > epair(4) in particular. The if_vmove shall not exist, instead we should do a > full > if_attach() and if_detach(). The state of an ifnet when it undergoes if_vmove > doesn't > carry any useful information. With Alexander melifaro@ we discussed better > options > for creating or attaching interfaces to jails that if_vmove. Until they are > ready > the most easy workaround to deal with annoying epair(4) come back problem is > to > remove it manually before destroying a jail, like I did in 80fc25025ff. >
It still behaved much better prior to eb93b99d6986, which you and Mark were going to work on a solution for to allow the cred "leak" to close up much more quickly. CC markj@, since I think it's been six months since the last time I inquired about it, making this a good time to do it again... Thanks, Kyle Evans
