From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52900 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753755AbeBSUBH (ORCPT ); Mon, 19 Feb 2018 15:01:07 -0500 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JJxi8D126751 for ; Mon, 19 Feb 2018 15:01:06 -0500 Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by mx0b-001b2d01.pphosted.com with ESMTP id 2g821008jv-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Feb 2018 15:01:06 -0500 Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Feb 2018 13:01:05 -0700 Subject: Re: [PATCH net] ibmvnic: Clean RX pools only during a hard reset To: David Miller Cc: netdev@vger.kernel.org, nfont@linux.vnet.ibm.com, jallen@linux.vnet.ibm.com References: <1518970121-8539-1-git-send-email-tlfalcon@linux.vnet.ibm.com> <20180219.113732.1002575230879716489.davem@davemloft.net> <93621ba4-4718-468d-5801-7c2f1b67c326@linux.vnet.ibm.com> <20180219.143057.1751495030105842591.davem@davemloft.net> From: Thomas Falcon Date: Mon, 19 Feb 2018 14:01:00 -0600 MIME-Version: 1.0 In-Reply-To: <20180219.143057.1751495030105842591.davem@davemloft.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Message-Id: <6bc62728-e3b0-a9ef-242b-abf3e9d1cc90@linux.vnet.ibm.com> Sender: netdev-owner@vger.kernel.org List-ID: On 02/19/2018 01:30 PM, David Miller wrote: > From: Thomas Falcon > Date: Mon, 19 Feb 2018 13:24:52 -0600 > >> Sorry, I should explain it better. It's not there is a double free. >> It's that the driver is receiving RX descriptors from the previous >> session for which socket buffers have been freed. The driver's >> polling routine tries to copy data to the socket buffer, but it's >> been freed, so it's trying to copy to a NULL pointer. > That's kinda hairy, is this resend of the old descriptors guaranteed > to always happen in this situation? > > Maybe it's better to have some way for the RX descriptor receiving > path to detect this situation (is SKB slot NULL?) to handle the > problem there. It is something we can expect to happen in this situation. Thanks for the suggestion. That way the driver can free up that memory when it closes. I'll try to get a v2 out soon. Thanks again. > Thanks. >