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 2FBD346BE5 for ; Tue, 22 Jul 2025 21:03:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 286E24003C; Tue, 22 Jul 2025 21:03:35 +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 8BA9340281 for ; Tue, 22 Jul 2025 21:03:33 +0200 (CEST) Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-700fee04941so56236246d6.1 for ; Tue, 22 Jul 2025 12:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uetpeshawar-edu-pk.20230601.gappssmtp.com; s=20230601; t=1753211013; x=1753815813; 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=GkCl42IuGJb041YjPIz910OLtN5TDRccv+8pZjlS2vQ=; b=Esh7tBu36U3SIitGsCQbe0nWAyYPfdFUo2336rIhukPCq6ymu9WXPMttn5gd21Df2l Sn/Q2QMRfUY8jZ8Naw0mC56jXHXIEesMHe2bXUIRPaRllkFD9+4E260qvYxH716sQXQB xAYmkxVt+IDU65Z0SbFoAl0q3dui5MhiwYS0BQflxQGy/608fjR2cs0hti3bpX1ZvRLf jwOrbpq3KN5gRHo7QvYaiReGc3otCC6g51chuGZ/jNpvI1f+iCDwB4W1Gj0A0RjQE9C4 YxkGis99KQ57WETmiv8wRi4q6AUrxiM7A08ZEVl6gftabhsZ3W2176bMCf+6CqEC/gRN n7sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753211013; x=1753815813; 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=GkCl42IuGJb041YjPIz910OLtN5TDRccv+8pZjlS2vQ=; b=slytdL1sJ173c8TnJYklbiWIV7PgPlS7ze15f//pIgoKpJFpK8K0ywb5oV4e2UZyPI +ooU17bsP1567EeRgidKkteFdDSFubw/1ciY21P0/C/qCXRXp4hAOPTzNVbD5cNp5xkO sKw7WgGFO6Qup3rPmY/AkuYLeQ1OJDwV/wVCYozBK24PKOUxG5SucZiEoujIo8zoPExa SNQClDE4ldY0KAXHxY/skBLpYud7czbL2Fvu82H2DFUtc4CtS7CQJSHodYgeOHG3RNtX O1ZDFZB3RFHmWv0PUHjKuurfv9mgsQEy1doA9gu3M0JVoB124qpbr/gXG03CyzctEHJf SqYQ== X-Forwarded-Encrypted: i=1; AJvYcCUXaROEGKwnsrTYusjZHZ/WKooKWm3n44OlsifKsKprQeKdo6HAPeBA71kLEa5OlvybEg1HOBs=@dpdk.org X-Gm-Message-State: AOJu0YxbtFu4qn8WtXTBHNceOpV4mPHoP8I6tl63L0chMZJCgwQ8hD85 Y2J94tZjez1LkRTnGg1iRrsWD6TBNP+OwKjxFFcoPWXbuB/g2t5Q7jG3P4iG6XBZ9w5uMq4iHCb 5WajclirVTvAGU/3ohfZ5FOU/yVz6wHYDeM/ri824qw== X-Gm-Gg: ASbGncv0o3TrRCVqjRhTMo5iePSpqO9UPw+qi8P+tdpfejklea31xPPV0oYCV2XV2P8 GstNondV/qnqj1Ek5FA/CNpcI7ALMqNLnPceuI0HRlG1B41vx4RKaZUG6cSAHo/GJRqB/5Wi6vo CY8ZxTWQi2i8X+Dfv3P6T42Hy1DsjU640OMWzMHbZxDi87RkWdGjrflagB2UxZ3XQwxxoIZhlLL 3Ioy61nHe5F1VtjiQkR/iKzaGER74HStH5UHP05pA== X-Google-Smtp-Source: AGHT+IH7QCSSSwPijZCK5E9LWSCxqJD7qvD6g2rI2mz9R9k8YIUzsCDMiM3acMbL+yBSRvuQfUC1rnglbk2jLRBfPoc= X-Received: by 2002:a05:6214:1d0d:b0:700:c7e4:cac6 with SMTP id 6a1803df08f44-7070058c6d5mr3396106d6.8.1753211012648; Tue, 22 Jul 2025 12:03:32 -0700 (PDT) MIME-Version: 1.0 References: <20250722115439.1353573-1-14pwcse1224@uetpeshawar.edu.pk> <20250722063924.2f87f3f7@hermes.local> <20250722084225.7a40e2bc@hermes.local> <20250722103824.7c9db0a0@hermes.local> <20250722112154.78349c82@hermes.local> In-Reply-To: <20250722112154.78349c82@hermes.local> From: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> Date: Wed, 23 Jul 2025 00:03:20 +0500 X-Gm-Features: Ac12FXxwo7rliNnEOujq5Yv2End3pc1YndA6Rh7cBsgAnhmVZs1dOQRHAJqhTrY Message-ID: Subject: Re: [PATCH] lib/ethdev: fix segfault in secondary process by validating dev_private pointer To: Stephen Hemminger Cc: Bruce Richardson , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org, dpdk stable Content-Type: multipart/alternative; boundary="000000000000a02e4c063a893f0c" 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 --000000000000a02e4c063a893f0c Content-Type: text/plain; charset="UTF-8" Right, those structures are accessed within each PMD, and I believe this shouldn't pose issues even on weakly ordered systems. As long as the checks are implemented using proper DPDK APIs, we can ensure correctness by enforcing appropriate memory ordering where needed, without introducing full locking overhead. On Tue, Jul 22, 2025, 23:21 Stephen Hemminger wrote: > On Tue, 22 Jul 2025 22:53:08 +0500 > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > Right, but performance and reliability are both important. While DPDK > > rightly prioritizes performance, some level of reliability should still > be > > ensured, especially to catch known issues that could lead to instability. > > > > On Tue, Jul 22, 2025, 22:38 Stephen Hemminger < > stephen@networkplumber.org> > > wrote: > > > > > On Tue, 22 Jul 2025 22:04:32 +0500 > > > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > > > > > Agree, but I think it's also a good practice to guard against known > cases > > > > that are prone to crashes. > > > > > > > > > Right but DPDK chooses performance over API safety. > > > For example rx/tx burst doesn't check args. > > > > > > The point is that as a library, if application is doing something wrong > > > returning error doesn't always help. > > > > > The problem is that all those values dev->data and private are shared > between processes without any locking. If the API's are going to MP safe > then they would require locking. The DPDK has made an explicit decision > to not use locking in ethdev control or data path. > > You can get away with checking for dev->data being NULL on x86 where > there is data consistency. But on weakly ordered platforms that is not > going > to work. > --000000000000a02e4c063a893f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, those structures are accessed within each PMD= , and I believe this shouldn't pose issues even on weakly ordered syste= ms. As long as the checks are implemented using proper DPDK APIs, we can en= sure correctness by enforcing appropriate memory ordering where needed, wit= hout introducing full locking overhead.

On Tue, = Jul 22, 2025, 23:21 Stephen Hemminger <stephen@networkplumber.org> wrote:
On Tue, 22 Jul 2025 22:53:08 +0500
Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote= :

> Right, but performance and reliability are both important. While DPDK<= br> > rightly prioritizes performance, some level of reliability should stil= l be
> ensured, especially to catch known issues that could lead to instabili= ty.
>
> On Tue, Jul 22, 2025, 22:38 Stephen Hemminger <stephen@netw= orkplumber.org>
> wrote:
>
> > On Tue, 22 Jul 2025 22:04:32 +0500
> > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk&g= t; wrote:
> >=C2=A0
> > > Agree, but I think it's also a good practice to guard ag= ainst known cases
> > > that are prone to crashes.=C2=A0
> >
> >
> > Right but DPDK chooses performance over API safety.
> > For example rx/tx burst doesn't check args.
> >
> > The point is that as a library, if application is doing something= wrong
> > returning error doesn't always help.
> >=C2=A0

The problem is that all those values dev->data and private are shared between processes without any locking. If the API's are going to MP saf= e
then they would require locking. The DPDK has made an explicit decision
to not use locking in ethdev control or data path.

You can get away with checking for dev->data being NULL on x86 where
there is data consistency. But on weakly ordered platforms that is not goin= g
to work.
--000000000000a02e4c063a893f0c--