From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [dpdk-dev] [Bug 816] KNI deadlocks while processing mac address set request with linux kernel version >= v5.12
Date: Tue, 28 Sep 2021 08:11:53 +0000 [thread overview]
Message-ID: <bug-816-3@http.bugs.dpdk.org/> (raw)
https://bugs.dpdk.org/show_bug.cgi?id=816
Bug ID: 816
Summary: KNI deadlocks while processing mac address set request
with linux kernel version >= v5.12
Product: DPDK
Version: 21.08
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: sahithi.singam@oracle.com
Target Milestone: ---
Starting from linux kernel version 5.12, a new global semaphore(dev_addr_sem)
was introduced in dev_set_mac_address_user() function that should be acquired
and released along with rtnl_lock when a mac address set request was received
from userspace.
This introduced following locking sequence in linux kernel ,
1. As part of dev_ioctl(), take rtnl_lock first
2. Then call down_write(&dev_addr_sem) in dev_set_mac_address_user()
3. Finally call kni_net_set_mac which calls kni_net_process_request.
4. In kni_net_process_request we will release only rtnl_lock but not
dev_addr_sem before we enqueue the request to req_q(i.e to userspace dpdk
process)
5. After receiving a response or timeout , we will again try to hold rtnl_lock
Above sequence in KNI is resulting in deadlock as we are just releasing
rtnl_lock without releasing semaphore while some other device could be waiting
for dev_addr_sem while holding rtnl_lock.
For example, if user issues two mac address set requests immediately on two kni
interfaces intf1, intf2. Then
1.intf1 takes rtnl_lock
2.intf1 takes dev_addr_sem
3.intf2 waits for rtnl_lock
4.intf1 in KNI , releases rtnl_lock
5.intf2 takes rtnl_lock and waits for dev_addr_sem held by intf1
6.intf1 at the end of kni request handling code, will try to lock rtnl_lock
held by intf2.
But intf2 will not release rtnl_lock as it was waiting for dev_addr_sem
held by intf1.
So at the end, intf1 will be holding dev_addr_sem and will be waiting for
rtnl_lock. intf2 will be holding rtnl_lock and will be waiting for dev_addr_sem
resulting in the KERNEL deadlock.
This issue started due to changes from
commitid:631217c761353aa5e4e548a20e570245ecbc8eda (kni: fix kernel deadlock
with bifurcated device)
and with linux kernel version >= v5.12
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2021-09-28 8:11 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=bug-816-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/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).