panic with jail bug_id 213673 was: VNET branch destiny

From: <peter.blok_at_bsd4all.org>
Date: Wed, 12 Apr 2017 16:03:05 +0200
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"
Received on Wed Apr 12 2017 - 12:03:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC