From owner-freebsd-net@freebsd.org  Thu Apr 20 10:43:53 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1237AD48C29
 for <freebsd-net@mailman.ysv.freebsd.org>;
 Thu, 20 Apr 2017 10:43:53 +0000 (UTC) (envelope-from zec@fer.hr)
Received: from mail.fer.hr (mail.fer.hr [161.53.72.233])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
 (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 9FB968C
 for <freebsd-net@freebsd.org>; Thu, 20 Apr 2017 10:43:52 +0000 (UTC)
 (envelope-from zec@fer.hr)
Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with
 Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr 2017 12:42:35 +0200
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>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [161.53.63.210]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 10:43:53 -0000

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