DPDK patches and discussions
 help / color / mirror / Atom feed
From: Edwin Brossette <edwin.brossette@6wind.com>
To: dev@dpdk.org
Cc: Didier Pallard <didier.pallard@6wind.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	 Laurent Hardy <laurent.hardy@6wind.com>,
	grive@u256.net
Subject: net/failsafe: segfault happens on hotplug alarm.
Date: Thu, 5 Sep 2024 18:07:12 +0200	[thread overview]
Message-ID: <CANDF9xBFJNz1h2vsLWoSCM+H2SMRDmv7gG5k2QtMq7voV34zNQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

Hello,

I recently ran into an issue when using DPDK's failsafe pmd on a Microsoft
Azure setup. On this setup, I have the failsafe pmd managing a netvsc
interface with a Mellanox nic (which can be used through the hardware
acceleration feature). A segfault is sometimes seen whenever I unplug the
Mellanox device, which is a case that should be handled by the pmd. On a
more recent DPDK version (I tested with stable v23.11.1), this segfault is
systematic.

This seems to happen because the function rte_eth_dev_release_port() is
called twice when the hotplug_alarm triggers. You can see it in this bit of
code here:
https://git.dpdk.org/dpdk/tree/drivers/net/failsafe/failsafe_ether.c#n276

In the fs_dev_remove() function, the rte_eth_dev_close() calls run the
rte_eth_dev_release_port() the first time, and it is then called a second
time when handling the DEV_PROBED case. I noticed when searching into the
mailing list that this problem was already seen once and a patch was
suggested. Here is the link to the mail:
https://mails.dpdk.org/archives/dev/2022-November/256898.html

Applying this patch on my local branched fixed the issue on my end although
I cannot attest for sure that it is the best possible fix. I could see a
memory leak happening if the fs_dev_remove() function was called as
sdev->state == DEV_PROBED, as the release would never be done. But it is
still weird that if sdev->state == DEV_STARTED, we do
rte_eth_dev_release_port() first then rte_dev_remove(), and if sdev->state
== DEV_PROBED, we call them in the opposite order.

Perhaps someone could look into it?

Regards,
Edwin Brossette.

[-- Attachment #2: Type: text/html, Size: 1866 bytes --]

                 reply	other threads:[~2024-09-05 16:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANDF9xBFJNz1h2vsLWoSCM+H2SMRDmv7gG5k2QtMq7voV34zNQ@mail.gmail.com \
    --to=edwin.brossette@6wind.com \
    --cc=dev@dpdk.org \
    --cc=didier.pallard@6wind.com \
    --cc=grive@u256.net \
    --cc=laurent.hardy@6wind.com \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).