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 1C2A146BF0 for ; Wed, 23 Jul 2025 13:29:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D39F40A87; Wed, 23 Jul 2025 13:29:19 +0200 (CEST) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by mails.dpdk.org (Postfix) with ESMTP id 22445402CC for ; Wed, 23 Jul 2025 13:29:16 +0200 (CEST) Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-70707b268b0so2213416d6.0 for ; Wed, 23 Jul 2025 04:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uetpeshawar-edu-pk.20230601.gappssmtp.com; s=20230601; t=1753270155; x=1753874955; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3nHtkL0L0iUZLJOvj1/O+XXPPlPshsp9c7Svd+AV0vA=; b=gzCywG5ORK03RXVLDDSxkADeLMLCnlj5u0/ygg90T90eMH+VkSCmZVeEM+HnNNAgHZ 4hH5OZdrUCt9rbWFirKY139x1LWEu22GmwYykJRxJMQIYGhpFrz+dXukcHXU7AkpVI45 SbjMB1BbTQrZmhQvd5ur6l3cbIf6rfS6CxPxEgiWjQ4DwdCUW2PDzuo9u2jYpo4xfOLN S9C7hUw9QaDCgy9hpc0H7HZt3dwb4YCZeR5V4xulx3V1jF1mWE+j/FTqr7QqonKfeIRq JYB9+ZfIaZgm4YYl2ygmOL5HHNpM5BbYRDbHa1It1IteqgarLi+LE+6Cijqh9fRK6f6i TD1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753270155; x=1753874955; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3nHtkL0L0iUZLJOvj1/O+XXPPlPshsp9c7Svd+AV0vA=; b=Yn40X5Lt2QDoYoZOJaWyMuU9iVvJS9sUeRl0NiVq4ZeK+CabKsHY08Iq3t7DmkRxYs mgwnp4XjTHGnEQuEmfYwgWCdEaTimAm6Ok4XHBPwOAOi489Q1xJxf4SOB9q/2cj11FkA tMvruXxA3YNfx5flXX0R7CPcOFHQJZwEEh4Xt+oEKmSgjLa2UbheVOYF3CFnun0W45Ax c6rIKjWHYCnztVmpaCHNyai4os+3XNvUFVt95EYxv9Hf60QWQe61yAcJqM469GwFE5da Vs2WHRpLwrb1a0Yh5DTaW16pTJs3peRZ/4qfjv114NTfo2VpOS3nQhTEGQWJqoaKhSa0 uxlQ== X-Forwarded-Encrypted: i=1; AJvYcCWUsstKrFI083qSuzb7qlUObIVukMB7py2fTxzvVmLWpsuCFnMH8B42SzQCexUZrQaF52ZsNtc=@dpdk.org X-Gm-Message-State: AOJu0YwNy8rDno0fl//afscRr97n9a2Fx41wA2pBsdd0Z6u2kHBtY9cD zG1HT9ZFH45wej2Ea+AcWInG3ImpYkdYx1gohjreCS6q1C3rWw1Ayul9thQQ0/s7FI7GNS8brNB KcabvU96J/igVQgLjFv9xPATBd/7Nu5Du8Q7AAVeHog== X-Gm-Gg: ASbGncuoNTyZiFfI6AgqZIWL3BQ4vBIsTNhzFYRKJoSfALo0g0R12WXMab8Q92mQSD1 4aAzyrB6k05U2jUz4aQqyYgjGXN5J6c7BRenXTlEERO+IbwQXJGEupla0owcnUEEmIG2BNdFCLi SHsVJzyOa4V+fZRE/kiK64qvzcNKZoq9gt5mBc0ooLWifuUOYGsFSwhUINx/HjICRf1jOeFcxBP 5wTGvP8dw== X-Google-Smtp-Source: AGHT+IHH3prw9wrcgMeLzTDgojADpoxf9g0petfy+gK0ZVlJHHIfIu0bewsPpFOtDm1V97JbHXsWC5xcT/H+GMGc364= X-Received: by 2002:a05:6214:1316:b0:6f5:3cae:920f with SMTP id 6a1803df08f44-707006f70cfmr33935006d6.27.1753270155151; Wed, 23 Jul 2025 04:29:15 -0700 (PDT) MIME-Version: 1.0 References: <20250721073851.963141-1-14pwcse1224@uetpeshawar.edu.pk> <20250721105819.2ci66fl7bzikwb22@ds-vm-debian.local> <3358342.oiGErgHkdL@thomas> In-Reply-To: From: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> Date: Wed, 23 Jul 2025 16:29:03 +0500 X-Gm-Features: Ac12FXwQ1OXC3Pfw_ZnLX1wTz_It9sZ8EIXKsICupNzidDG1wCbUKCN0vDLOvLo Message-ID: Subject: Re: [PATCH] net/mlx5: fix crash when secondary queries dev info after primary exits To: Thomas Monjalon Cc: Dariusz Sosnowski , Ivan Malov , Andrew Rybchenko , dev@dpdk.org, rasland@nvidia.com, dpdk stable , Viacheslav Ovsiienko , Bing Zhao , Ori Kam , Suanming Mou , Matan Azrad Content-Type: multipart/alternative; boundary="000000000000cb273f063a970495" 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 --000000000000cb273f063a970495 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This patch is a logical continuation of the commit: ``` commit 30410493759f ("drivers/net: check process type in close operation") ``` In that change, @Thomas Monjalon introduced a mechanism to prevent secondary processes from incorrectly releasing shared resources during device close operations. That patch enforced process-type checks in PMD close functions, ensuring only primary processes could manage shared resources. Furthermore, secondary application not only breaking on device closing, it's also getting segfault when we do "show device info all" from secondary after primary closes: testpmd> show device info all ********************* Infos for device 0000:03:00.0 ********************* Bus name: pci Bus information: vendor_id=3D15b3, device_id=3D101d Driver name: mlx5_pci Devargs: Connect to socket: 0 Segmentation fault (core dumped) This patch prevents these crashes and it seems that these fixes should be in PMD along with the ethdev layer. On Wed, Jul 23, 2025 at 12:30=E2=80=AFAM Khadem Ullah < 14pwcse1224@uetpeshawar.edu.pk> wrote: > I think at least this should be followed either in PMD or in ethdev layer > to avoid this specific crashes. > > On Mon, Jul 21, 2025, 17:00 Thomas Monjalon wrote: > >> 21/07/2025 13:46, Ivan Malov: >> > On Mon, 21 Jul 2025, Dariusz Sosnowski wrote: >> > >> > > + mlx5 maintainers >> > > >> > > Thank you for the patch. >> > > >> > > Could you please include other PMD maintainers (or other maintainers= , >> depending on changed code) >> > > in the future patches? >> > > There is a script which automatically adds maintainers while sending >> a patch. >> > > It is described in: >> https://doc.dpdk.org/guides/contributing/patches.html#sending-patches >> > > >> > > On Mon, Jul 21, 2025 at 03:38:51AM -0400, Khadem Ullah wrote: >> > >> When the primary process exits, the shared mlx5 state becomes >> > >> unavailable to secondary processes. If a secondary process attempts >> > >> to query device information (e.g., via testpmd), a NULL dereference >> > >> may occur due to missing shared data. >> > >> >> > >> This patch adds a check for shared context availability and fails >> > >> gracefully while preventing a crash. >> > >> >> > >> Fixes: e60fbd5b24fc ("mlx5: add device configure/start/stop") >> > >> Cc: stable@dpdk.org >> > >> >> > >> Signed-off-by: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> >> > >> --- >> > >> drivers/net/mlx5/mlx5_ethdev.c | 6 ++++++ >> > >> 1 file changed, 6 insertions(+) >> > >> >> > >> diff --git a/drivers/net/mlx5/mlx5_ethdev.c >> b/drivers/net/mlx5/mlx5_ethdev.c >> > >> index 68d1c1bfa7..1848f6536a 100644 >> > >> --- a/drivers/net/mlx5/mlx5_ethdev.c >> > >> +++ b/drivers/net/mlx5/mlx5_ethdev.c >> > >> @@ -368,6 +368,12 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, >> struct rte_eth_dev_info *info) >> > >> * Since we need one CQ per QP, the limit is the minimum number >> > >> * between the two values. >> > >> */ >> > >> + if (priv =3D=3D NULL || priv->sh =3D=3D NULL) { >> > >> + DRV_LOG(ERR, >> > >> + "mlx5 shared data unavailable (primary process likely >> exited)"); >> > >> + rte_errno =3D ENODEV; >> > >> + return -rte_errno; >> > >> + } >> > > >> > > I don't think it's an issue on PMD level, but rather on >> > > ethdev/multi-process handling level. >> > >> > I may be very wrong here, but can't the PMD use its internal 'shared' >> state to >> > somehow memorise the fact that a secondary process has attached, in >> order to not >> > let the primary process close in the first place (before the secondary >> process >> > detaches)? Or is this going to violate some established convention? >> >> It looks to be a good idea. >> >> > > When primary process closes the port, ethdev library zeroes and free= s >> > > device data shared between processes. >> > > ethdev port data (rte_eth_dev) on secondary is not updated so it now >> points to >> > > invalid data. rte_eth_dev_info_get() is not the only API call >> affected. >> > > >> > > If the primary process closes the port before exiting >> > > (like testpmd does) and it exits before the secondary, >> > > the any driver call seems invalid because of that use-after-free >> behavior. >> > > >> > > @Thomas, @Andrew - Do you happen to know if doing anything on ethdev >> ports >> > > in secondary process after primary has gracefully exited is supporte= d? >> >> No there is no statement about whether it is supported or not. >> I think we should at least return an error instead of crashing. >> >> >> --=20 Engr. Khadem Ullah, Software Engineer, Dreambig Semiconductor Inc https://dreambigsemi.com/ --000000000000cb273f063a970495 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This patch is a logical continuation of the commit:
```
commit 30410493759f ("drivers/net: check process type in close= operation")
```

In that change,=C2=A0@Thomas Monjalon=C2=A0 introduced a mechanism to prevent second= ary processes from incorrectly releasing shared resources during device clo= se operations. That patch enforced process-type checks in PMD close functio= ns, ensuring only primary processes could manage shared resources.

F= urthermore, secondary application not only breaking on device closing, it&#= 39;s also getting segfault when we do "show device info all" from= secondary after primary closes:

testpmd> show device info all <= br>
********************* Infos for device 0000:03:00.0 ****************= *****
Bus name: pci
Bus information: vendor_id=3D15b3, device_id=3D10= 1d
Driver name: mlx5_pci
Devargs:
Connect to socket: 0

Seg= mentation fault (core dumped)

This patch prevents these crashes and = it seems that these fixes should be in PMD along with the ethdev layer. =C2= =A0


On Wed, Jul 23, 2025 at 12:30=E2=80=AFAM K= hadem Ullah <14pwcse12= 24@uetpeshawar.edu.pk> wrote:
I think at least this should be foll= owed either in PMD or in ethdev layer to avoid this specific crashes.=C2=A0=

= On Mon, Jul 21, 2025, 17:00 Thomas Monjalon <thomas@monjalon.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">21/07/2025 13:46, Ivan Mal= ov:
> On Mon, 21 Jul 2025, Dariusz Sosnowski wrote:
>
> > + mlx5 maintainers
> >
> > Thank you for the patch.
> >
> > Could you please include other PMD maintainers (or other maintain= ers, depending on changed code)
> > in the future patches?
> > There is a script which automatically adds maintainers while send= ing a patch.
> > It is described in: https://doc.dpdk.org/guides/contributing/patches.html#sending-p= atches
> >
> > On Mon, Jul 21, 2025 at 03:38:51AM -0400, Khadem Ullah wrote:
> >> When the primary process exits, the shared mlx5 state becomes=
> >> unavailable to secondary processes. If a secondary process at= tempts
> >> to query device information (e.g., via testpmd), a NULL deref= erence
> >> may occur due to missing shared data.
> >>
> >> This patch adds a check for shared context availability and f= ails
> >> gracefully while preventing a crash.
> >>
> >> Fixes: e60fbd5b24fc ("mlx5: add device configure/start/s= top")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Khadem Ullah <14pwcse1224@uetpe= shawar.edu.pk>
> >> ---
> >>=C2=A0 drivers/net/mlx5/mlx5_ethdev.c | 6 ++++++
> >>=C2=A0 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx= 5/mlx5_ethdev.c
> >> index 68d1c1bfa7..1848f6536a 100644
> >> --- a/drivers/net/mlx5/mlx5_ethdev.c
> >> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> >> @@ -368,6 +368,12 @@ mlx5_dev_infos_get(struct rte_eth_dev *d= ev, struct rte_eth_dev_info *info)
> >>=C2=A0 =C2=A0 =C2=A0* Since we need one CQ per QP, the limit i= s the minimum number
> >>=C2=A0 =C2=A0 =C2=A0* between the two values.
> >>=C2=A0 =C2=A0 =C2=A0*/
> >> +=C2=A0 if (priv =3D=3D NULL || priv->sh =3D=3D NULL) { > >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DRV_LOG(ERR,
> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "mlx5 shared data un= available (primary process likely exited)");
> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rte_errno =3D ENODEV;
> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -rte_errno;
> >> +=C2=A0 }
> >
> > I don't think it's an issue on PMD level, but rather on > > ethdev/multi-process handling level.
>
> I may be very wrong here, but can't the PMD use its internal '= shared' state to
> somehow memorise the fact that a secondary process has attached, in or= der to not
> let the primary process close in the first place (before the secondary= process
> detaches)? Or is this going to violate some established convention?
It looks to be a good idea.

> > When primary process closes the port, ethdev library zeroes and f= rees
> > device data shared between processes.
> > ethdev port data (rte_eth_dev) on secondary is not updated so it = now points to
> > invalid data. rte_eth_dev_info_get() is not the only API call aff= ected.
> >
> > If the primary process closes the port before exiting
> > (like testpmd does) and it exits before the secondary,
> > the any driver call seems invalid because of that use-after-free = behavior.
> >
> > @Thomas, @Andrew - Do you happen to know if doing anything on eth= dev ports
> > in secondary process after primary has gracefully exited is suppo= rted?

No there is no statement about whether it is supported or not.
I think we should at least return an error instead of crashing.




--
Engr. Khadem Ullah,
= Software Engineer,
<= span style=3D"color:rgb(12,100,192)">Dreambig Semiconductor Inc
=
--000000000000cb273f063a970495--