Date: Thu, 20 Apr 2017 12:42:56 +0200 From: Marko Zec <zec@fer.hr> To: <peter.blok@bsd4all.org> Cc: <freebsd-net@freebsd.org> Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <20170420124256.1190665d@x23> In-Reply-To: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Apr 2017 21:31:50 +0200
<peter.blok@bsd4all.org> wrote:
...
> I also have a change in zone_release to fix another panic and leak in
> slab_free_item. The issue is that zone_release tries to release a keg
> that never belonged to the zone it is trying to release. With my
> limited knowledge, i think that should not happen.
>
> --- vm/uma_core.c (revision 317156)
> +++ vm/uma_core.c (working copy)
> @@ -2846,7 +2846,8 @@
> KEG_LOCK(keg);
> }
> }
> - slab_free_item(keg, slab, item);
> + if (keg == slab->us_keg)
> + slab_free_item(keg, slab, item);
> if (keg->uk_flags & UMA_ZFLAG_FULL) {
> if (keg->uk_pages < keg->uk_maxpages) {
> keg->uk_flags &= ~UMA_ZFLAG_FULL;
>
This change only masks the cause of the panic while still continuing to
leak memory, and should never be commited.
The real culprit lies somewhere in PF code which operates on a wrong
vnet. Without a backtrace it's difficult to guess, but a quick read
reveals that
pfi_initialize()
is called from the default vnet context, and subsequently registers
interface eventhandlers so that all interface attach, change and detach
events will be always executed in the default vnet, regardless of the
real vnet where the interfaces bound to the events actually reside. In
other words,
pfi_attach_group_event()
pfi_change_group_event()
pfi_detach_group_event()
will operate fine only in the default vnet, but will wreak havoc
otherwise. Hence, those handlers should be fixed first.
Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170420124256.1190665d>