VNET branch destiny

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

VNET branch destiny

timp
Hello, dear freebsd-current@!

There was FreeBSD Foundation report back in 2016Q2 where it told us
about VNET (VIMAGE) update project sponsored by foundation.
What is the current situation? Is it committed into base? If not
what's the plan?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Bjoern A. Zeeb
On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

> Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

timp
31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
[hidden email]> написал:

On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?
>

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz


Thanks a lot for the reply!
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

vt(4) bugs needing attention

Ernie Luzar
In reply to this post by Bjoern A. Zeeb



Is anyone working the these outstanding vt(4) bug reports?

Bug 210431 - vt(4) copy/paste mode does not work in hw.vga.textmode=1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210431

Bug 210432 - vt(4) does not support boot time splash screen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210432

Bug 210446 - vt(4) when switching between virtual consoles there is a 4
second hesitation in graph mode.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210446


Are fixes for these going to be in 11.1 release?



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: vt(4) bugs needing attention

Ed Maste-2
On 1 April 2017 at 13:28, Ernie Luzar <[hidden email]> wrote:
>
> Is anyone working the these outstanding vt(4) bug reports?

I am not aware of anyone working on these right now.

> Bug 210446 - vt(4) when switching between virtual consoles there is a 4
> second hesitation in graph mode.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210446

I am not able to reproduce this issue on any of my hardware. This is
most likely going to require significant investigation by someone who
has an affected system with a serial console, so that we can determine
where the delay is occurring.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

timp
In reply to this post by Bjoern A. Zeeb
31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
[hidden email]> написал:

On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?
>

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz


Sorry, do you know if there is any plan to include VNET into GENERIC?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

peter.blok
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.

Peter

> On 10 Apr 2017, at 08:50, Pavel Timofeev <[hidden email]> wrote:
>
> 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
> [hidden email]> написал:
>
> On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:
>
> Hello, dear freebsd-current@!
>>
>> There was FreeBSD Foundation report back in 2016Q2 where it told us
>> about VNET (VIMAGE) update project sponsored by foundation.
>> What is the current situation? Is it committed into base? If not
>> what's the plan?
>>
>
> Changes are in 12 and 11.   12 has seen more slight fixes due to other
> changes that other committers are tracking and I hope they merge to 11.
>
> /bz
>
>
> Sorry, do you know if there is any plan to include VNET into GENERIC?
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Ernie Luzar
[hidden email] 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.
>
> Peter

PF was fixed in 11.0 to not panic when run on a host that has vimage
compiled into the kernel. On 11.0 you can configure pf to run in a vnet
jail but it really does not enforce any firewall rules because pf needs
access to the kernel which jail(8) is blocking by design. As far as I
know this is a show shopper that can not be fixed without a pf rewrite
changing the way it works internally.

This PR gives all the details
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

peter.blok
Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my intention to use the netgrpah bridge with bhyve as well.

The panic (one-time) happened in pfioctl when I refreshed the rules. I suspect the problem is related to the following message when I stop the jail.

kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost -57 pages of memory.

Current does not display the UMA message. I’m still narrowing down what happens with the pf table entries. My suspicion is that the netgraph bridge which creates a ng_ether device which is handed over to the jail vnet, is causing this.


The panic happened on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
        uma_slab_t slab;
        int reserve;

        mtx_assert(&keg->uk_lock, MA_OWNED);
        slab = NULL;
        reserve = 0;
        if ((flags & M_USE_RESERVE) == 0)
                reserve = keg->uk_reserve;

        for (;;) {
                /*
                 * Find a slab with some space.  Prefer slabs that are partially
                 * used over those that are totally full.  This helps to reduce
                 * fragmentation.
                 */
                if (keg->uk_free > reserve) {
                        if (!LIST_EMPTY(&keg->uk_part_slab)) {
                                slab = LIST_FIRST(&keg->uk_part_slab);
                        } else {
                                slab = LIST_FIRST(&keg->uk_free_slab);
                                LIST_REMOVE(slab, us_link);
                                LIST_INSERT_HEAD(&keg->uk_part_slab, slab,
                                    us_link);
                        }
                        MPASS(slab->us_keg == keg);
                        return (slab);
                }

KDB: stack backtrace:
#0 0xffffffff805df0e7 at kdb_backtrace+0x67
#1 0xffffffff8059d176 at vpanic+0x186
#2 0xffffffff8059cfe3 at panic+0x43
#3 0xffffffff808ebaa2 at trap_fatal+0x322
#4 0xffffffff808ebaf9 at trap_pfault+0x49
#5 0xffffffff808eb336 at trap+0x286
#6 0xffffffff808d1441 at calltrap+0x8
#7 0xffffffff808a871e at zone_fetch_slab+0x6e
#8 0xffffffff808a87cd at zone_import+0x4d
#9 0xffffffff808a4fc9 at uma_zalloc_arg+0x529
#10 0xffffffff80803214 at pfr_ina_define+0x584
#11 0xffffffff807f0734 at pfioctl+0x3364
#12 0xffffffff80469288 at devfs_ioctl_f+0x128
#13 0xffffffff805fa925 at kern_ioctl+0x255
#14 0xffffffff805fa65f at sys_ioctl+0x16f
#15 0xffffffff808ec604 at amd64_syscall+0x6c4
#16 0xffffffff808d172b at Xfast_syscall+0xfb

The panic is so far not reproducible.


> On 10 Apr 2017, at 15:50, Ernie Luzar <[hidden email]> wrote:
>
> [hidden email] 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.
>> Peter
>
> PF was fixed in 11.0 to not panic when run on a host that has vimage compiled into the kernel. On 11.0 you can configure pf to run in a vnet jail but it really does not enforce any firewall rules because pf needs access to the kernel which jail(8) is blocking by design. As far as I know this is a show shopper that can not be fixed without a pf rewrite changing the way it works internally.
>
> This PR gives all the details
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Ernie Luzar
In reply to this post by peter.blok
To the VNET (VIMAGE) update project team members

Release 11.0 has some out standing VNET (VIMAGE) PR's that need addressing.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212000

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212031

I believe 212000 and 212013 would require an rewrite replacing the
kernel method they use to the user land method as used by ipfw. At the
very lease it should be documented somewhere that pf & ipfilter do not
work in an vnet/vimage jail.

PR 212031 looks like a vimage/vnet problem to me.


To the members of current, This bug report is not a jail(8) problem but
a kernel problem that needs to be addressed. Could someone please look
into fixing it. I effects all jail(8) users.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210049

There is also the matter of removing the depreciated rc.conf jail
definition method from the rc.d scripts making the jail.conf method the
default. This is long over due and maybe something over looked in the
11.0 release.


Thank you for your attention.




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Ernie Luzar
In reply to this post by peter.blok
[hidden email] wrote:

> Well, in my case it panic’ed on 11-stable. I’m only using pf on the
> host, not in the jail. I’m using Devin Teske’s jng to create a netgraph
> bridge. It is my intention to use the netgrpah bridge with bhyve as well.
>
> The panic (one-time) happened in pfioctl when I refreshed the rules. I
> suspect the problem is related to the following message when I stop the
> jail.
>
> kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost
> -57 pages of memory.
>
> Current does not display the UMA message. I’m still narrowing down what
> happens with the pf table entries. My suspicion is that the netgraph
> bridge which creates a ng_ether device which is handed over to the
> jail vnet, is causing this.
>
>
> The panic happened on LIST_REMOVE in keg_fetch_slab
>
> static uma_slab_t
> keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
> {
>         uma_slab_t slab;
>         int reserve;
>
>         mtx_assert(&keg->uk_lock, MA_OWNED);
>         slab = NULL;
>         reserve = 0;
>         if ((flags & M_USE_RESERVE) == 0)
>                 reserve = keg->uk_reserve;
>
>         for (;;) {
>                 /*
>                  * Find a slab with some space.  Prefer slabs that are
> partially
>                  * used over those that are totally full.  This helps to
> reduce
>                  * fragmentation.
>                  */
>                 if (keg->uk_free > reserve) {
>                         if (!LIST_EMPTY(&keg->uk_part_slab)) {
>                                 slab = LIST_FIRST(&keg->uk_part_slab);
>                         } else {
>                                 slab = LIST_FIRST(&keg->uk_free_slab);
>                                 *LIST_REMOVE(slab, us_link);*
>                                 LIST_INSERT_HEAD(&keg->uk_part_slab, slab,
>                                     us_link);
>                         }
>                         MPASS(slab->us_keg == keg);
>                         return (slab);
>                 }
>
> KDB: stack backtrace:
> #0 0xffffffff805df0e7 at kdb_backtrace+0x67
> #1 0xffffffff8059d176 at vpanic+0x186
> #2 0xffffffff8059cfe3 at panic+0x43
> #3 0xffffffff808ebaa2 at trap_fatal+0x322
> #4 0xffffffff808ebaf9 at trap_pfault+0x49
> #5 0xffffffff808eb336 at trap+0x286
> #6 0xffffffff808d1441 at calltrap+0x8
> #7 0xffffffff808a871e at zone_fetch_slab+0x6e
> #8 0xffffffff808a87cd at zone_import+0x4d
> #9 0xffffffff808a4fc9 at uma_zalloc_arg+0x529
> #10 0xffffffff80803214 at pfr_ina_define+0x584
> #11 0xffffffff807f0734 at pfioctl+0x3364
> #12 0xffffffff80469288 at devfs_ioctl_f+0x128
> #13 0xffffffff805fa925 at kern_ioctl+0x255
> #14 0xffffffff805fa65f at sys_ioctl+0x16f
> #15 0xffffffff808ec604 at amd64_syscall+0x6c4
> #16 0xffffffff808d172b at Xfast_syscall+0xfb
>
> The panic is so far not reproducible.
>
>
>> On 10 Apr 2017, at 15:50, Ernie Luzar <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> [hidden email] <mailto:[hidden email]> 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.
>>> Peter
>>
>> PF was fixed in 11.0 to not panic when run on a host that has vimage
>> compiled into the kernel. On 11.0 you can configure pf to run in a
>> vnet jail but it really does not enforce any firewall rules because pf
>> needs access to the kernel which jail(8) is blocking by design. As far
>> as I know this is a show shopper that can not be fixed without a pf
>> rewrite changing the way it works internally.
>>
>> This PR gives all the details
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
>>
>>

I also tested using Devin Teske’s jng to create a netgraph bridge on
RELEASE 10.0 and it worked. But when I tried the same configuration on
RELEASE 11.0 it no longer worked.

I strongly suggest you verify pf is functional in your vnet jail before
you go chasing a dump which I suspect is totally misleading.

Setup a simple vnet pf rule set being run in the vnet jail that allows
everything out except port 43 which the "whois" command uses and then
issue the whois command from the vent jail console. If the vnet pf port
43 rule is really blocking port 43 it will cause the whois command to
not return any results. If the whois command returns results this
indicates that even thought you have all the correct settings to run pf
in your vnet jail and have received no error messages about it, pf is
not really enforcing any rules. (IE; not working)  I am assuming that
the host has no firewall at all or is at least allowing outbound port 43
packets out.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Ernie Luzar
In reply to this post by peter.blok
[hidden email] wrote:
> Well, in my case it panic’ed on 11-stable. I’m only using pf on the
> host, not in the jail. I’m using Devin Teske’s jng to create a netgraph
> bridge. It is my intention to use the netgrpah bridge with bhyve as well.
>


I also tested using Devin Teske’s jng to create a netgraph bridge on
RELEASE 10.0 and it worked. But when I tried the same configuration on
RELEASE 11.0 it no longer worked.

Sorry for the noise. I missed this sentence. "I’m only using pf on the
host, not in the jail.". Thats what happens when I answer email after a
long day at work.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

peter.blok
No problem. Although pf is not used the vnet_destroy seems to be the issue. Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown happens on the host vnet so to speak.


> On 10 Apr 2017, at 22:11, Ernie Luzar <[hidden email]> wrote:
>
> [hidden email] wrote:
>> Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my intention to use the netgrpah bridge with bhyve as well.
>
>
> I also tested using Devin Teske’s jng to create a netgraph bridge on
> RELEASE 10.0 and it worked. But when I tried the same configuration on
> RELEASE 11.0 it no longer worked.
>
> Sorry for the noise. I missed this sentence. "I’m only using pf on the
> host, not in the jail.". Thats what happens when I answer email after a long day at work.
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Bjoern A. Zeeb
On 10 Apr 2017, at 20:59, [hidden email] wrote:

> No problem. Although pf is not used the vnet_destroy seems to be the
> issue. Some parts are not virtualized and the
> vnet_destroy->vnet_pf_uninit teardown happens on the host vnet so to
> speak.

The base system VNET is not shutdown;  it never was.   Module unload
however could be a possible scenario.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Ari Suutari-3
In reply to this post by Ernie Luzar
Hi,

There is also this one:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673

It's about memory leak with pf tables + vnet, but the problem results
in panic, which is quite easily reproduced.

      Ari S.


On 10.4.2017 17:39, Ernie Luzar wrote:

> To the VNET (VIMAGE) update project team members
>
> Release 11.0 has some out standing VNET (VIMAGE) PR's that need
> addressing.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212000
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212031
>
> I believe 212000 and 212013 would require an rewrite replacing the
> kernel method they use to the user land method as used by ipfw. At the
> very lease it should be documented somewhere that pf & ipfilter do not
> work in an vnet/vimage jail.
>
> PR 212031 looks like a vimage/vnet problem to me.
>
>
> To the members of current, This bug report is not a jail(8) problem
> but a kernel problem that needs to be addressed. Could someone please
> look into fixing it. I effects all jail(8) users.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210049
>
> There is also the matter of removing the depreciated rc.conf jail
> definition method from the rc.d scripts making the jail.conf method
> the default. This is long over due and maybe something over looked in
> the 11.0 release.
>
>
> Thank you for your attention.
>
>
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

Kristof Provost-3
In reply to this post by peter.blok
On 10 Apr 2017, at 12:10, [hidden email] 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 ([hidden email]) on the report.

Thanks,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: VNET branch destiny

peter.blok
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 <[hidden email]> wrote:
>
> On 10 Apr 2017, at 12:10, [hidden email] 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 ([hidden email]) on the report.
>
> Thanks,
> Kristof

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

panic with jail bug_id 213673 was: VNET branch destiny

peter.blok
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, [hidden email] 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 <[hidden email]> wrote:
>>
>> On 10 Apr 2017, at 12:10, [hidden email] 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 ([hidden email]) on the report.
>>
>> Thanks,
>> Kristof
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"