From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 05552A052A;
	Wed, 27 Jan 2021 12:44:52 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 8C37B140CEF;
	Wed, 27 Jan 2021 12:44:52 +0100 (CET)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by mails.dpdk.org (Postfix) with ESMTP id 34E3B140CEE;
 Wed, 27 Jan 2021 12:44:49 +0100 (CET)
IronPort-SDR: SVoCDyyz1yitZWacZH2mo9nzZXO7zaesM8GqYj67K3Zi/AsXP97yotrMs6jUCag2yVPlL57JJo
 IDynOZj1VpcA==
X-IronPort-AV: E=McAfee;i="6000,8403,9876"; a="180134975"
X-IronPort-AV: E=Sophos;i="5.79,379,1602572400"; d="scan'208";a="180134975"
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 27 Jan 2021 03:44:46 -0800
IronPort-SDR: U5dIaX0xxFYpxX7eR/SwOq5MYB4lTRt/6Utl/92kSrehfLP7EiWLMe/uovp7kuAzc79GTEt9BR
 wusS2DRjOzhA==
X-IronPort-AV: E=Sophos;i="5.79,379,1602572400"; d="scan'208";a="430076250"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.208.215])
 ([10.213.208.215])
 by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 27 Jan 2021 03:44:45 -0800
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
 Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org
Cc: stable@dpdk.org, Anatoly Burakov <anatoly.burakov@intel.com>,
 Liron Himi <lironh@marvell.com>,
 Stephen Hemminger <stephen@networkplumber.org>
References: <20210122175804.772207-1-thomas@monjalon.net>
 <e96f6ae7-0be7-5ad7-dd8c-f731d7443b54@oktetlabs.ru>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <d87e5b94-10a3-ab6a-02bd-78303497f678@intel.com>
Date: Wed, 27 Jan 2021 11:44:41 +0000
MIME-Version: 1.0
In-Reply-To: <e96f6ae7-0be7-5ad7-dd8c-f731d7443b54@oktetlabs.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 1/1] ethdev: fix handling of
 close failure
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 1/25/2021 9:13 AM, Andrew Rybchenko wrote:
> On 1/22/21 8:58 PM, Thomas Monjalon wrote:
>> If a failure happens when closing a port,
>> it was unnecessarily failing again in the function eth_err(),
>> because of a check against HW removal cause.
>> Indeed there is a big chance the port is released at this point.
>> Given the port is in the middle (or at the end) of a close process,
>> checking the error cause by accessing the port is a non-sense.
>> The error check is replaced by a simple return in the close function.
>>
>> Bugzilla ID: 624
>> Fixes: 8a5a0aad5d3e ("ethdev: allow close function to return an error")
>> Cc: stable@dpdk.org
>>
>> Reported-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> 

Applied to dpdk-next-net/main, thanks.