Thanks for the follow up.
Understood. That makes sense. However, I’d 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 [off-list ref]
wrote:

On Tue, 22 Jul 2025 19:30:41 +0500
Khadem Ullah [off-list ref] wrote:

quoted

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>

quoted

wrote:

quoted

On Tue, 22 Jul 2025 07:54:39 -0400
Khadem Ullah [off-list ref] wrote:

quoted

+     if (rte_eal_process_type() == RTE_PROC_SECONDARY &&
+             (dev == NULL || dev->data == NULL ||
+             dev->data->dev_private == 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.