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 D181646BE9 for ; Tue, 22 Jul 2025 18:01:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B4D0A4003C; Tue, 22 Jul 2025 18:01:57 +0200 (CEST) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by mails.dpdk.org (Postfix) with ESMTP id 993CC40269 for ; Tue, 22 Jul 2025 18:01:56 +0200 (CEST) Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-6fabe9446a0so48887436d6.2 for ; Tue, 22 Jul 2025 09:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uetpeshawar-edu-pk.20230601.gappssmtp.com; s=20230601; t=1753200116; x=1753804916; 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=wORt9mImnXn/wMv5HXX5lrWHxoz1xX8Qt477OBtTa2g=; b=qztuXg5BSPcMIvCUfv6m/rpUdgVxlUihIWCGphMwnYeHqS3kJSK98txC/mlJx9TthF 5Kr2v3tYc/7WEGI5e34DZWi87EpxcbTK7fq+Ahi4Iu+UWHFT4sZsXAxxZcvGW1KuE+p8 KOoZZAj9Q3zOVKE45mzPSDQKOcP1JTCEMr7NocxM7M170N51pJHOJxpZGNvhQd5ojfHx WWLZeEuuHvcpjkVbNhFeL4Hxcw83ATBqPPRjtl5BLHYPLMouRG/6S/UwYbWGtUTZ14yV 7rwleSY1KU1Xka9SNagOpXtsR/P/H1I6J5uw5nfX7xWDa2+tIHvTacpszw7ooanwxEpn 3Krw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753200116; x=1753804916; 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=wORt9mImnXn/wMv5HXX5lrWHxoz1xX8Qt477OBtTa2g=; b=KfkJAattZTR+OOkf/weVT7Q98Zb22AbT+0ym3/HkaaFaB6Wq8YRYUevrCT7A9TMFze jNlf+8ewo6xAsnTaPYmWCfN/mGPfL2RU7iQsDJLHTdR8XvMaus1iLJFtJtgu+YgLYGT+ NXVJDnP58uVTTTk0VR0tiLHtvO95CiedOZqnukQM4MKq/f8n2LISFf+Wi1n7J+j1v5D2 XmOLIvtWM2i7D5GCYjqu4w0bEO89mki6lIQ368tYUntmBFqDW7Yu09VOSUucIpaFhTIF 1Vx2DOxhblk0H5zQHn1IpWHGP98MFwHz98AIdXTya7d7oY6a6qsM5etk7GtkfZzqAEjs sReA== X-Forwarded-Encrypted: i=1; AJvYcCXpWk8UQaxrfv4/+eCenQCQkeyCEvs5CFJSqJf8SUcXLr0Qq6ZO5s3SjvCUtO2cvT5wrr06iOk=@dpdk.org X-Gm-Message-State: AOJu0Yx46DvBoB2UN6dZUl6Rhf8RQcNuoU2lwIfENXQmOw/3i4x/pqQA Uib1enqVQ5em7fVUVPo5lF4qbhRlxD5ex7ebn+UYjs/J+deWzN3fGcOzG2FMJUYLyw+0dpGRKeD aDpDm/VnajK0GIjrdiaBTZgxPrSk5rmAF4mH1cIEfbA== X-Gm-Gg: ASbGncsZqG3WHBN2Cew/4Ban9UCXJCStk18tj5i+y2jML2xpTCk0hNJ0bkGhayRXVUb 0hb1nVD7mAbgAcEOzjf1cv+6VBqex0mOJ/zpNdw2vQf4cf0X6zNW6zJnXWy6diiJzApzvhp5c3Y 9+tFte/a/pI/p/diVxZo/c2SbsbEtt4emo/RCY0XG5mRQbppKpmpJYj28DKN9AIMBBiZsehQ3Uz 2uPuKa6wxszcif6DZi5Ku+KODglVo2bOH7T+blqcA== X-Google-Smtp-Source: AGHT+IGYBL8rlo8opIjsWVn2vYAiVEZH/xL3Yaam4u60i/QDAQ83xSZBni+DeLyxplUPzPP09s6dcuer0nmhzMQIF+Y= X-Received: by 2002:a05:6214:5788:b0:6fb:25f:ac8c with SMTP id 6a1803df08f44-704f4ab51famr389761616d6.31.1753200115680; Tue, 22 Jul 2025 09:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20250722115439.1353573-1-14pwcse1224@uetpeshawar.edu.pk> <20250722063924.2f87f3f7@hermes.local> <20250722084225.7a40e2bc@hermes.local> In-Reply-To: <20250722084225.7a40e2bc@hermes.local> From: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> Date: Tue, 22 Jul 2025 21:01:42 +0500 X-Gm-Features: Ac12FXxzG7qugzFE7IIUOFB3eIwY4a8sF3iXMjVQAY3isUs49HdWdmQwf-cKDNI Message-ID: Subject: Re: [PATCH] lib/ethdev: fix segfault in secondary process by validating dev_private pointer To: Stephen Hemminger Cc: Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org, dpdk stable Content-Type: multipart/alternative; boundary="0000000000001d9ab1063a86b624" 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 --0000000000001d9ab1063a86b624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the follow up. Understood. That makes sense. However, I=E2=80=99d like to highlight that applications should ideally be robust and interactive enough to handle all edge cases where a segfault or unexpected error might occur. While clear documentation is certainly important, relying solely on it may not be sufficient. In my view, potential segfaults should be handled explicitly in code to ensure stability and to prevent silent failures, especially in production environments. On Tue, Jul 22, 2025, 20:42 Stephen Hemminger wrote: > On Tue, 22 Jul 2025 19:30:41 +0500 > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > Hi Stephen, > > Can we add only the check that fixes the segfault, or do you mean that = it > > should be fixed at the PMD level? > > > > Best regards, > > Khadem > > > > On Tue, Jul 22, 2025, 18:39 Stephen Hemminger < > stephen@networkplumber.org> > > wrote: > > > > > On Tue, 22 Jul 2025 07:54:39 -0400 > > > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > > > > > + if (rte_eal_process_type() =3D=3D RTE_PROC_SECONDARY && > > > > + (dev =3D=3D NULL || dev->data =3D=3D NULL || > > > > + dev->data->dev_private =3D=3D NULL || > > > > > > dev can't be NULL and checking it here will cause a Coverity warning. > > > > > > There are many other ethdev calls that will fail if primary dies. > > > stats, xstats, rx/tx burst, ... > > > > > > I don't think it is good idea to add checks here. > > > > > It needs to be fixed at the documentation level. > Make sure and document what applications need to do. Rather than adding > more checks in ethdev. > --0000000000001d9ab1063a86b624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the follow up.=C2=A0
Understo= od. That makes sense. However, I=E2=80=99d like to highlight that applicati= ons should ideally be robust and interactive enough to handle all edge case= s where a segfault or unexpected error might occur. While clear documentati= on is certainly important, relying solely on it may not be sufficient. In m= y view, potential segfaults should be handled explicitly in code to ensure = stability and to prevent silent failures, especially in production environm= ents.


On Tue, Jul 22= , 2025, 20:42 Stephen Hemminger <stephen@networkplumber.org> wrote:
On Tue, 22 Jul 2025 19:30:41 +0500
Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote= :

> Hi Stephen,
> Can we add only the check that fixes the segfault, or do you mean that= it
> should be fixed at the PMD level?
>
> Best regards,
> Khadem
>
> On Tue, Jul 22, 2025, 18:39 Stephen Hemminger <stephen@netw= orkplumber.org>
> wrote:
>
> > On Tue, 22 Jul 2025 07:54:39 -0400
> > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk&g= t; wrote:
> >=C2=A0
> > > +=C2=A0 =C2=A0 =C2=A0if (rte_eal_process_type() =3D=3D RTE_P= ROC_SECONDARY &&
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(dev =3D=3D= NULL || dev->data =3D=3D NULL ||
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev->dat= a->dev_private =3D=3D NULL ||=C2=A0
> >
> > dev can't be NULL and checking it here will cause a Coverity = warning.
> >
> > There are many other ethdev calls that will fail if primary dies.=
> > stats, xstats, rx/tx burst, ...
> >
> > I don't think it is good idea to add checks here.
> >=C2=A0

It needs to be fixed at the documentation level.
Make sure and document what applications need to do. Rather than adding
more checks in ethdev.
--0000000000001d9ab1063a86b624--