Date: Thu, 20 Apr 2017 14:08:20 +0200 From: peter.blok@bsd4all.org To: Marko Zec <zec@fer.hr> Cc: freebsd-net@freebsd.org Subject: Re: MFC VIMAGE fixes to 11-stable Message-ID: <0E874FFD-735D-443C-A92E-F00E3737441C@bsd4all.org> In-Reply-To: <20170420124256.1190665d@x23> References: <8E6FC1CD-24D5-46D5-A6A1-760DD612F92D@bsd4all.org> <20170420124256.1190665d@x23>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marko,
Thanks for the pointer. It was not my intention to have this committed, =
but it helped identify other problems. I have asked this before in =
-current, but got no answer so I posted it here to get an answer.
If you look inside slab_free_item there is a KASSERT for just this, so =
that=E2=80=99s why I tried it.
I have added debug information to print the zone=E2=80=99s and the =
keg=E2=80=99s and It all looked good. I was not able to find any place =
where we operated on the wrong context, but perhaps I missed one.
I=E2=80=99ll dig further.
Peter
> On 20 Apr 2017, at 12:42, Marko Zec <zec@fer.hr> wrote:
>=20
> 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.
>>=20
>> --- 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 =3D=3D 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 &=3D ~UMA_ZFLAG_FULL;
>>=20
>=20
> This change only masks the cause of the panic while still continuing =
to
> leak memory, and should never be commited.
>=20
> 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
>=20
> pfi_initialize()
>=20
> 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,
>=20
> pfi_attach_group_event()
> pfi_change_group_event()
> pfi_detach_group_event()
>=20
> will operate fine only in the default vnet, but will wreak havoc
> otherwise. Hence, those handlers should be fixed first.
>=20
> Marko
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E874FFD-735D-443C-A92E-F00E3737441C>