Date: Sat, 7 Jul 2012 20:38:23 +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: <E909B0C0-F4DE-4110-B151-98FAC9330B82@lists.zabbadoz.net> In-Reply-To: <86zk7da10y.fsf@in138.ua3> References: <4FF32FC4.6020701@delphij.net> <86wr2kau38.fsf@in138.ua3> <4FF5E87C.2020908@delphij.net> <86r4sqasrt.fsf@kopusha.home.net> <672D93D3-D4B1-432E-AE53-98E6C05B8BE4@lists.zabbadoz.net> <86zk7da10y.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6. Jul 2012, at 05:53 , Mikolaj Golub wrote: >=20 > On Thu, 5 Jul 2012 20:21:53 +0000 Bjoern A. Zeeb wrote: >=20 > BAZ> On 5. Jul 2012, at 19:53 , Mikolaj Golub wrote: >=20 >>>=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 -) >=20 > BAZ> To me the patch looks wrong; I am wondering if someone broke some = other central > BAZ> assumptions but given I cannot currently spend time on this and = if it fixes things > BAZ> feel free to go ahead. >=20 > If you told what looks wrong I could try to dig at that direction and = might be > back with a better solution, instead of committing a presumably wrong = fix. sorry; vnet.c:vnet_destroy() should dtrt already wrt to interfaces = moving to parents and being detached. /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?E909B0C0-F4DE-4110-B151-98FAC9330B82>