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).