Skip site navigation (1)Skip section navigation (2)
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>