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 D3CDC48AFC for ; Thu, 13 Nov 2025 16:11:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC77640BA4; Thu, 13 Nov 2025 16:11:26 +0100 (CET) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by mails.dpdk.org (Postfix) with ESMTP id 3915240A79 for ; Thu, 13 Nov 2025 16:11:24 +0100 (CET) Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8b25ed53fcbso125193785a.0 for ; Thu, 13 Nov 2025 07:11:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763046683; x=1763651483; 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=8lB8u5Rfjm8UML7hLRplCn8AdXPEPUoOIzGUfpHmucc=; b=kyoqpZ44K6K8XRBUutVw9ixN0gLNVmd8DS3Pc7CkwpBqeR8a+/nrFfwSH/XTPmz1YK jF4tsY5oKlQbCo2CHjOVgQDr1r33wPEk9TBOw5GOYcPRd+eO7r6OSqqQSYNGirlWcg3B wMSJobCA87nKqvlv8//ZKte7sb9g/F2u7cvrjzdqcTSFm4AvU7vr/Gf1fw+P+ahMfzdp l2dmZ85bu3yyRxoUVl6C6wjIGX9gIxfP8K435u6DoW7hM4yfzbBggCh+JQdx6tOk0rbm RbDzJox2joFrIjvGfcvZRElbbFMIJmUWXTVTKwv2890X/3y/A4gU/r2kNnFZCVBnheKs sWkg== X-Forwarded-Encrypted: i=1; AJvYcCWzUp1A0rEtNHeqJV2h1D5b86R0CJG6rVCrdNXYmJUuexZRwrMKpTCcDTWwqLdoFGrq2QI1TUc=@dpdk.org X-Gm-Message-State: AOJu0YzJ9C6I4zf1r9RGpY1Bp5vfco3hull5oaiE4Om+hKJfdXObp894 uXvVbSAkxQTsA45Re1sUBbCe78RIC6VddGRp8zuvIGCH5oUgpsi4gvO6Kp6DbvbcAY4qR4lRebb 6Jaw6KVvSW9iRji+Ug4xztRfnGbWIRNA= X-Gm-Gg: ASbGncsB+CiY7NNEEgLJ77IyKkqOOVa+xxREkitAcmasWSh8M9fLWXNebWO9xpmKrDd 0EO16fanmIGTbBX+UpdIyItwvM+JGvt1uD+PDV4lR0H0mA8HGkawv43Ruqf4T/8INlZB30rnvwi EdfCZneLk0Y/1Zvewjyd2E9BznHfQZ3NgO/UGDyxX4pIqtVPn7xCSOhtdPd2I7rk35y/ICeR+80 V3Zky/hoPdqS5QMtLWSU8BxMg3fX0LjMdVIjon5lXIp8mfl/Ssi48OYCQ== X-Google-Smtp-Source: AGHT+IGgaDMUQj8XYvsSJrHFGTLEcJ4dlwpfWFl7hWGdS+MUjC8B46hGEieGwGh6Y/jua7RPOyuE8lgs0Nhj8B+BMPA= X-Received: by 2002:a05:620a:29d2:b0:8a1:b435:984a with SMTP id af79cd13be357-8b29b7df70emr791753385a.69.1763046683471; Thu, 13 Nov 2025 07:11:23 -0800 (PST) MIME-Version: 1.0 References: <20251113095917.1973514-1-hemant.agrawal@nxp.com> <20251113114355.2027438-1-hemant.agrawal@nxp.com> In-Reply-To: <20251113114355.2027438-1-hemant.agrawal@nxp.com> From: Maxime Leroy Date: Thu, 13 Nov 2025 16:11:12 +0100 X-Gm-Features: AWmQ_bnMvF-AoQpVUmTr3zWhDDagw6CEeLsJlB0sp710vs3htsvhQE2I9pmfRz8 Message-ID: Subject: Re: [PATCH v4 1/4] net/dpaa2: fix duplicate calling of dpaa2 dev close To: Hemant Agrawal Cc: dev@dpdk.org, stephen@networkplumber.org, david.marchand@redhat.com, sachin.saxena@nxp.com, stable@dpdk.org 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 Hi Hemant, Le jeu. 13 nov. 2025 =C3=A0 12:44, Hemant Agrawal = a =C3=A9crit : > > 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 | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_e= thdev.c > index 7da32ce856..fc63cf4f09 100644 > --- a/drivers/net/dpaa2/dpaa2_ethdev.c > +++ b/drivers/net/dpaa2/dpaa2_ethdev.c > @@ -3347,14 +3347,19 @@ 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 rte_eth_dev_allocated(dpaa2_dev->device.name); > + if (eth_dev) { > + dpaa2_dev_close(eth_dev); > + ret =3D rte_eth_dev_release_port(eth_dev); > + } dpaa2_dev_close() returns a status code, but it isn=E2=80=99t being checked= here. For comparison, in rte_eth_dev_pci_generic_remove(), if dev_uninit (i.e. the device close callback) fails, rte_eth_dev_release_port() is not called. How should the dpaa2 driver handle this kind of error case? By the way, if it makes sense for you, feel free to add a Tested-by tag from me, since I=E2=80=99ve validated the series on my side with Grout. Regards, Maxime Leroy