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 3C34A46BE9; Tue, 22 Jul 2025 19:04:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 62B5740658; Tue, 22 Jul 2025 19:04:46 +0200 (CEST) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by mails.dpdk.org (Postfix) with ESMTP id 85991402D1 for ; Tue, 22 Jul 2025 19:04:44 +0200 (CEST) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-704c5464aecso52145946d6.0 for ; Tue, 22 Jul 2025 10:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uetpeshawar-edu-pk.20230601.gappssmtp.com; s=20230601; t=1753203884; x=1753808684; 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=+6nm2nKHozcyion3xY5lKUM2umgsLPFZgJYfURHy0Bg=; b=Y7OOYu4ThPOtA08sZfcA3i5CC3w8nRTfGjguATvV2KAbN6tovOLalAOOqwYEZXtkYn 7k85LNKXpkoKG7cGM5eUGQjCl01TD45KL3UywdwlJZYOHypLN9oEkU0n+r2Q58oqLKBu Oq0xmXKZhKikogSS5MapX2XyJrV6ELKHEJyDfhCrdUbWSQAak6rTdcpOWFeEPHJWu6EB FwMCr2mTtW6EqU9N/tQbmJI/t8IXQ6hwdwWGrv9o8rnQEZk2va14RQO5sVwv12DHepYD P5IRhjyZULrdqiR6BoOk986VA3GeaNwpwuK5Q+eGbR9fWjy/0cZK0i/W1rcPinH/bsK9 q+pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753203884; x=1753808684; 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=+6nm2nKHozcyion3xY5lKUM2umgsLPFZgJYfURHy0Bg=; b=IOjei9ceyYSuiiYA6RmcvUI/rAjgZzSQlsFiYWZ67pJi8wRqJBfXx95S4KxzcWybMr j696ByARq5R6ZrL3S9VsxPaT+j6zpkFiwc96z4IZTqBBqW6cvzJf6ykwF6uB/v4W+/iy jwlV+HoHptHVvStsmbePsnAoj5Zod7JMNcD4WRRUHGtPMdKo8+ZfV99CINW8bFMdED6J kab6pTAk80BYXOiG5LDwQFg5zSL6pgMlpRrt6o5YCRmPZM2orxsaDs06gbzBDrlnC5kI WTCZA1QZHIRF8Uf4UByiyaoGEylWey2ZP+VSAWA+Nco47ReSobObBxvfjeTLjRW/jQDN ++ew== X-Forwarded-Encrypted: i=1; AJvYcCVlX7cOjLuWy2M8wmyF6/pT83mGMus4jqEidRAzj6F3URHV509PCgrhmRFQ94Ne3A2agZM=@dpdk.org X-Gm-Message-State: AOJu0YzrS/jfTdnXrZW2kKxePFK+hDuFiyr+SrbAhOfA58pcm8e2jfQh A4w9rAXx1YmVWUy1QVJ6UEKqL4U/0N9ISx/mCUdq+UAzVaD9seckDLUu7MSRf3mZT3mddIU6xIL Fk5OaIJ4ljCNTiBzPCJ4jfgTc3XxpGmfY9YtvqorE1A== X-Gm-Gg: ASbGncviqkaI5bWzo0PGqxAi6dtOi1M02TFzYw87z5V9YMVvHx6a/5sEbp82D25sNwM SNHkftymUUdQMxuHQVzZfakQKwZw0iKmxt4j38gRv4pohbeWVJmlmEPG+XJh8AKRQEI1tUnbRxR dlgD5t/zxcP7yikce//HyvscOw3I+8b0z04IWQjG5gNW2t7unGyDV6hj09QXyZJuKaNG71u2kW9 9WEefHhu6d20ELRiA== X-Google-Smtp-Source: AGHT+IGDDz5V+FBcnNatJm85yI5IKCZr7ai0tRPzkQhIUlyZS9igW8+6L8HuqtZ2LWJhNRpehihQCoO5r5e7kkebqIo= X-Received: by 2002:a05:6214:194c:b0:702:d3c8:5e1e with SMTP id 6a1803df08f44-704f66ed6c9mr298226646d6.0.1753203883624; Tue, 22 Jul 2025 10:04:43 -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: From: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> Date: Tue, 22 Jul 2025 22:04:32 +0500 X-Gm-Features: Ac12FXzjfx4-tkVa0I_LuZ8_leqxSKC6PeTUiyReXaa9HSl4_Lks2_5qmEgITy8 Message-ID: Subject: Re: [PATCH] lib/ethdev: fix segfault in secondary process by validating dev_private pointer To: Bruce Richardson Cc: Stephen Hemminger , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org, dpdk stable Content-Type: multipart/alternative; boundary="000000000000b3df1d063a879670" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000b3df1d063a879670 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree, but I think it's also a good practice to guard against known cases that are prone to crashes. On Tue, Jul 22, 2025 at 9:14=E2=80=AFPM Bruce Richardson wrote: > On Tue, Jul 22, 2025 at 09:01:42PM +0500, Khadem Ullah wrote: > > 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 hand= le > > all edge cases where a segfault or unexpected error might occur. Whi= le > > 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 failure= s, > > especially in production environments. > > > In fairness, where stability is the main concern, I'd generally recommend > avoiding multi-process entirely. Or, if it has to be used, the primary > process should be a minimal slim one, that sets up the ports and memory a= nd > thereafter sleeps so that it should never crash unexpectedly! > > Even with that, if any secondary process dies, you'll still have all the > buffers in use by that secondary process leaked, so for any multiprocess > system the only safe behaviour for the system is to restart all processes > if any process unexpectedly terminate. > > /Bruce > --=20 Engr. Khadem Ullah, Software Engineer, Dreambig Semiconductor Inc https://dreambigsemi.com/ --000000000000b3df1d063a879670 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree, but I think it's also a good practice to guard = against known cases that are prone to crashes.=C2=A0

O= n Tue, Jul 22, 2025 at 9:14=E2=80=AFPM Bruce Richardson <bruce.richardson@intel.com> wrote:
On Tue, Jul 22, 20= 25 at 09:01:42PM +0500, Khadem Ullah wrote:
>=C2=A0 =C2=A0 Thanks for the follow up.
>=C2=A0 =C2=A0 Understood. That makes sense. However, I=E2=80=99d like t= o highlight that
>=C2=A0 =C2=A0 applications should ideally be robust and interactive eno= ugh to handle
>=C2=A0 =C2=A0 all edge cases where a segfault or unexpected error might= occur. While
>=C2=A0 =C2=A0 clear documentation is certainly important, relying solel= y on it may
>=C2=A0 =C2=A0 not be sufficient. In my view, potential segfaults should= be handled
>=C2=A0 =C2=A0 explicitly in code to ensure stability and to prevent sil= ent failures,
>=C2=A0 =C2=A0 especially in production environments.
>
In fairness, where stability is the main concern, I'd generally recomme= nd
avoiding multi-process entirely. Or, if it has to be used, the primary
process should be a minimal slim one, that sets up the ports and memory and=
thereafter sleeps so that it should never crash unexpectedly!

Even with that, if any secondary process dies, you'll still have all th= e
buffers in use by that secondary process leaked, so for any multiprocess system the only safe behaviour for the system is to restart all processes if any process unexpectedly terminate.

/Bruce


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