Date: Tue, 10 Jul 2012 00:15:24 +0300 From: Mikolaj Golub <trociny@freebsd.org> To: d@delphij.net Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r238309 - head/sys/net Message-ID: <86sjd0vdoz.fsf@kopusha.home.net> In-Reply-To: <4FFB43CD.4070802@delphij.net> (Xin Li's message of "Mon, 09 Jul 2012 13:49:17 -0700") References: <201207092038.q69KcIi1038787@svn.freebsd.org> <4FFB43CD.4070802@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 09 Jul 2012 13:49:17 -0700 Xin Li wrote: XL> On 07/09/12 13:38, Mikolaj Golub wrote: >> Author: trociny Date: Mon Jul 9 20:38:18 2012 New Revision: >> 238309 URL: http://svn.freebsd.org/changeset/base/238309 >> >> Log: In epair_clone_destroy(), when destroying the second half, we >> have to switch to its vnet before calling ether_ifdetach(). >> Otherwise if the second half resides in a different vnet, >> if_detach() silently fails leaving a stale pointer in V_ifnet list, >> and the system crashes trying to access this pointer later. >> >> Another solution could be not to allow to destroy epair unless >> both ends are in the home vnet. >> >> Discussed with: bz Tested by: delphij XL> Thanks! XL> Since this affects RELENG_9 and RELENG_8, could you please also MFC XL> after a settle period? Sure. Just forgot to add the 'MFC after' reminder. I am going to MFC it after stable/9 unfreeze unless someone really wants it in 9.1 and tests it a little. This does not look like a critical issue because of the existing workaround (which can be considered as a best practice): move both ends to the home vnet before destroying the epair. -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86sjd0vdoz.fsf>