Date: Thu, 5 Jul 2012 20:21:53 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Mikolaj Golub <trociny@freebsd.org> Cc: d@delphij.net, FreeBSD virtualization mailing list <freebsd-virtualization@FreeBSD.org> Subject: Re: GPF when doing jail -r, possibly an use-after-free Message-ID: <672D93D3-D4B1-432E-AE53-98E6C05B8BE4@lists.zabbadoz.net> In-Reply-To: <86r4sqasrt.fsf@kopusha.home.net> References: <4FF32FC4.6020701@delphij.net> <86wr2kau38.fsf@in138.ua3> <4FF5E87C.2020908@delphij.net> <86r4sqasrt.fsf@kopusha.home.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5. Jul 2012, at 19:53 , Mikolaj Golub wrote: >=20 > On Thu, 05 Jul 2012 12:18:20 -0700 Xin Li wrote: >=20 > XL> Hi, Mikolaj, >=20 > XL> On 07/04/12 00:00, Mikolaj Golub wrote: >>> Is this observed after destroying epair? There is an issue with >>> epair: on destroy, when epair_clone_destroy() calls >>> ether_ifdetach() for its second half it does not switch to its vnet >>> and if_detach_internal() can't find the interface and just returns. >>> As a result V_ifnet list is left with dead reference. >=20 > XL> Yes. >=20 >>> = http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-January/000= 628.html >>>=20 >>> Here is an updated patch against CURRENT: >>>=20 >>> = http://people.freebsd.org/~trociny/if_epair.c.epair_clone_destroy.1.patch >=20 > XL> Your >>>=20 > XL> patch did fixed the problem, thanks! Are you going to commit it > XL> against -HEAD and then MFC after a while? >=20 > I would like Bjoern review it before me committing, or at least tell = he does > not mind, if he does not have time to review -) To me the patch looks wrong; I am wondering if someone broke some other = central assumptions but given I cannot currently spend time on this and if it = fixes things feel free to go ahead. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?672D93D3-D4B1-432E-AE53-98E6C05B8BE4>