From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E8BA137AF for ; Fri, 3 Jul 2015 18:04:32 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 03 Jul 2015 09:04:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,400,1432623600"; d="scan'208";a="599658420" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.62]) by orsmga003.jf.intel.com with SMTP; 03 Jul 2015 09:04:27 -0700 Received: by (sSMTP sendmail emulation); Fri, 03 Jul 2015 17:04:26 +0025 Date: Fri, 3 Jul 2015 17:04:26 +0100 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150703160425.GC8096@bricha3-MOBL3> References: <1435938006-22254-1-git-send-email-bruce.richardson@intel.com> <1435938006-22254-3-git-send-email-bruce.richardson@intel.com> <1879755.kzD1mjHoUo@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1879755.kzD1mjHoUo@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 2/2] ixgbe: check mbuf refcnt when clearing RX/TX ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 16:04:33 -0000 On Fri, Jul 03, 2015 at 05:46:55PM +0200, Thomas Monjalon wrote: > 2015-07-03 16:40, Bruce Richardson: > > The function to clear the TX ring when a port was being closed, e.g. on > > exit in testpmd, was not checking the mbuf refcnt before freeing it. > > Since the function in the vector driver to clear the ring after TX does > > not set the pointer to NULL post-free, this caused crashes if mbuf > > debugging was turned on. > > Please, could you add a Fixes: line to reference the origin of the bug? > Thanks What benefit does that information provide? Given that this bug occurs in two places in the code, and has been there for some time, I'm not sure that a straight lookup of the commit that last changed the line(s) would identify the true source of the bug. Because of that, I'd like to know the information is really going to be useful before making an effort to track it down. :-) /Bruce