From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9B9B848A92 for ; Fri, 7 Nov 2025 09:32:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 955D84021F; Fri, 7 Nov 2025 09:32:59 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id B708B4021F for ; Fri, 7 Nov 2025 09:32:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762504378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uXLJ0hGq5jrU8xUawgp3whdVkqRSV1x6p7zGPm36vX4=; b=d6nvZSkSxa9LJOciftkdqFG6Ko+IHSCgc0GgH2TIhfEsJ35hu+YxyiEdhpaV0PgBovCjkV xQVWTxDpkd44J9F1Fw1t/zF6DdGpaalvzpO/6CKBcD+T3DgmtFpRt7BN1ZHKAL91Le2EU4 eZcVjE/h0YsDNcRM18GSyshhCgquxgo= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-bWMRgI7XP2qmMkoG0MWzzg-1; Fri, 07 Nov 2025 03:32:57 -0500 X-MC-Unique: bWMRgI7XP2qmMkoG0MWzzg-1 X-Mimecast-MFC-AGG-ID: bWMRgI7XP2qmMkoG0MWzzg_1762504376 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-59436279838so440030e87.0 for ; Fri, 07 Nov 2025 00:32:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762504375; x=1763109175; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uXLJ0hGq5jrU8xUawgp3whdVkqRSV1x6p7zGPm36vX4=; b=QF5aSftbj3ACWvv23jBtj+dzd5LkdmUkOaqtODb/Ng0m+FOClgH+gnWWLiqd8Vml12 Q+PJJZNI0b6EyM0jDyXGxy7qQByS9+5K8cy/WYyMpIpQLuJpqC7+AethlUwB/PAM6CyN /0ESHFJBMUDQW7kNCaoppBgSJwkeYom65IzwaST1KcPZgxD1WlALESChsPJk+OGYhvef tCK6E/YMZNpZj4yXRKDrSo6lm0kdSQbddihWkO7qAY4CnWxanjtFXNv85nCPwF0I4oQz 80K9Vsy/jj4BBhX7ik1bgO4YOyheckL4DzHerjdZq9YVRA8l9dxHtsXXkcroIFj/sKeA BVYw== X-Forwarded-Encrypted: i=1; AJvYcCXlLZBemkrziRy/oDdia1ZkxlBwJWjTy1MfztLrux1V6HFlE0EOtwCF3GmHEoBY1M0KfDbS86Q=@dpdk.org X-Gm-Message-State: AOJu0Yx2BrORQvCIb0sW4XCfFNseDzNDKB9TaozE8BaS1Mae1pPGZb+x Kd7H4sb3ezFpEV5mSQJ++dw2Bsyj0BpvBdHfWDW0L6PKStPb+5DsqD1Yw4cYssJu08FJKimcHMM cqMLVJe2+Sw3hghjlPj5WUPZAEhj0xyE6WRceiTmoA2KYEewnTlJ8HlkxTcyVczJcYqHQ8p437A prwqGbynsU/6x7+VrPWioR8+k= X-Gm-Gg: ASbGncubs9kT8URJrb/fP6k9tvzXcDacQQPr2nckFCZVSFzyGwiXnHfIYu81uvVg64j FQF5ID7btyN2mGism856TRa6iNAQd5q9I8+hDwDVqR+OdrRj3jMlWGSXuj3jjDNiYQY8W4y3Ez9 LDyijEQRn7zI7YVo2xj9mM2xkuUaNhitijYnsix72Ag52sJsCF6oRogGEyWg== X-Received: by 2002:ac2:4e06:0:b0:594:4b55:d2dc with SMTP id 2adb3069b0e04-59456cbefa1mr798975e87.47.1762504375437; Fri, 07 Nov 2025 00:32:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IHCUp4flH2IxxMWWqjtTTYD0Z5djjqgSkV0rr/REDQrat8pO3UGyl/hRYQcHTTGfKiEqCXphfXOawXCsvqp+Ls= X-Received: by 2002:ac2:4e06:0:b0:594:4b55:d2dc with SMTP id 2adb3069b0e04-59456cbefa1mr798955e87.47.1762504374948; Fri, 07 Nov 2025 00:32:54 -0800 (PST) MIME-Version: 1.0 References: <20251106163807.201451-1-hemant.agrawal@nxp.com> In-Reply-To: <20251106163807.201451-1-hemant.agrawal@nxp.com> From: David Marchand Date: Fri, 7 Nov 2025 09:32:42 +0100 X-Gm-Features: AWmQ_bnacEtClyo-EX5Xks2hRm5fWpSBHaVlm_nbYrqIhVenR1Ru5JxOOu1u3v4 Message-ID: Subject: Re: [PATCH 1/3] net/dpaa2: fix duplicate calling of dpaa2 dev close To: Hemant Agrawal Cc: dev@dpdk.org, stephen@networkplumber.org, sachin.saxena@nxp.com, stable@dpdk.org, maxime@leroys.fr X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EZSDclGP8t__3NS3a_SUatQ4bY_nVKj19hothRDKwlw_1762504376 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hello, On Thu, 6 Nov 2025 at 17:38, Hemant Agrawal wrote: > > When rte_eth_dev_close() is called, it performs the following actions: > > Calls dev->dev_ops->dev_close(), which in this case is dpaa2_dev_close(). > Then calls rte_eth_dev_release_port(), which releases all device data > and sets dev->data to NULL. > > Later, when rte_dev_remove() is called, the FSLMC bus invokes > dev->remove() =E2=80=94 that is, rte_dpaa2_remove(). > However, rte_dpaa2_remove() calls dpaa2_dev_close() again. Since dev->dat= a > was already set to NULL by the previous call, this second invocation > causes a crash. > > Fixes: 5964d36a2904 ("net/dpaa2: release port upon close") > Cc: sachin.saxena@nxp.com > Cc: stable@dpdk.org > > Signed-off-by: Hemant Agrawal > --- > drivers/net/dpaa2/dpaa2_ethdev.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_e= thdev.c > index 7da32ce856..f3db7982a4 100644 > --- a/drivers/net/dpaa2/dpaa2_ethdev.c > +++ b/drivers/net/dpaa2/dpaa2_ethdev.c > @@ -3347,14 +3347,17 @@ static int > rte_dpaa2_remove(struct rte_dpaa2_device *dpaa2_dev) > { > struct rte_eth_dev *eth_dev; > - int ret; > + int ret =3D 0; > > eth_dev =3D dpaa2_dev->eth_dev; Having a back reference of the "class" object in a "device" object seems wrong to me (and there is a dev_priv->eth_dev too...). It breaks the separation that was introduced with rte_device years ago. I did not look in detail, but it seems strange that after closing a first time, there would still remain a reference of the eth_dev object in the dpaa2 device object. At least, it would be worth double checking that the dpaa2_dev->eth_dev is cleared in dpaa2_dev_close. > - dpaa2_dev_close(eth_dev); > + if (eth_dev->data) { > + ret =3D dpaa2_dev_close(eth_dev); > + if (!ret) > + ret =3D rte_eth_dev_release_port(eth_dev); I don't see why you would need to decrement dpaa2_valid_dev again below. Maybe a missing return here? > + } > dpaa2_valid_dev--; > if (!dpaa2_valid_dev) > rte_mempool_free(dpaa2_tx_sg_pool); > - ret =3D rte_eth_dev_release_port(eth_dev); > > return ret; > } Taking a step back, the issue this patch wants to fix is a pattern that is resolved by other drivers by checking if a eth_dev is allocated for a rte_device. A simpler (untested) fix seems to be: diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_eth= dev.c index 7da32ce856..6682a72341 100644 --- a/drivers/net/dpaa2/dpaa2_ethdev.c +++ b/drivers/net/dpaa2/dpaa2_ethdev.c @@ -3349,7 +3349,10 @@ rte_dpaa2_remove(struct rte_dpaa2_device *dpaa2_dev) struct rte_eth_dev *eth_dev; int ret; - eth_dev =3D dpaa2_dev->eth_dev; + eth_dev =3D rte_eth_dev_allocated(dpaa2_dev->device.name); + if (!eth_dev) + return 0; + dpaa2_dev_close(eth_dev); dpaa2_valid_dev--; if (!dpaa2_valid_dev) --=20 David Marchand