panic with jail bug_id 213673 was: VNET branch destiny

peter.blok at bsd4all.org peter.blok at bsd4all.org
Wed Apr 12 14:03:18 UTC 2017


The problem happens when stopping a jail. It doesn’t seem to be related to vnet at all.

When stopping a jail, pfr_cleanup calls uma_zdestroy(V_pfr_kentry_z). The dtor calls zone_release, which calls slab_free_item. The issue seems to be that the keg found in zone_release does not belong to the zone that is to be destroyed, but belongs to the zone that is created for the same purpose at the host. The zone belongs to the jail (verified). The added if (marked with XXX) fixes the problem.

I don’t understand how a keg ends up in a different zone.

zone_release(uma_zone_t zone, void **bucket, int cnt)
{
        void *item;
        uma_slab_t slab;
        uma_keg_t keg;
        uint8_t *mem;
        int clearfull;
        int i;
                
        clearfull = 0;
        keg = zone_first_keg(zone);
        KEG_LOCK(keg);
        for (i = 0; i < cnt; i++) {
                item = bucket[i];
                if (!(zone->uz_flags & UMA_ZONE_VTOSLAB)) {
                        mem = (uint8_t *)((uintptr_t)item & (~UMA_SLAB_MASK));
                        if (zone->uz_flags & UMA_ZONE_HASH) {
                                slab = hash_sfind(&keg->uk_hash, mem);
                        } else {
                                mem += keg->uk_pgoff;
                                slab = (uma_slab_t)mem;
                        }
                } else {
                        slab = vtoslab((vm_offset_t)item);
                        if (slab->us_keg != keg) {
                                KEG_UNLOCK(keg);
                                keg = slab->us_keg;
                                KEG_LOCK(keg);
                        }
                }
                if (keg == slab->us_keg)				// XXX seems to fix the problem
                        slab_free_item(keg, slab, item);

> On 11 Apr 2017, at 13:43, peter.blok at bsd4all.org wrote:
> 
> Hi Kristof,
> 
> I’m prety sure it is the same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673>. It is unrelated to epair or ng_eiface (my case).
> 
> I’ll dig some more.
> 
> Peter
> 
> 
>> On 11 Apr 2017, at 08:47, Kristof Provost <kristof at sigsegv.be> wrote:
>> 
>> On 10 Apr 2017, at 12:10, peter.blok at bsd4all.org wrote:
>>> There have been issues with pf if I recall correctly. I currently have issues with stable, pf and vnet. There is an issue with pf table entries when an interface is moved to a different vnet.
>>> 
>>> Does anyone no if there is a specific fix for this that hasn’t been ported to stable? I haven’t had the time to test this on current.
>>> 
>> I’m currently aware of at least some issues with pf and vnet, even in CURRENT.
>> Not that one though, so can you make sure there’s a bug report with as much detail as possible?
>> Please also cc me (kp at freebsd.org) on the report.
>> 
>> Thanks,
>> Kristof
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"



More information about the freebsd-current mailing list