DPDK patches and discussions
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [Bug 1298] memif disconnect thread vs. rx_burst worker thread(s) crash
Date: Thu, 12 Oct 2023 15:37:37 +0000	[thread overview]
Message-ID: <bug-1298-3@http.bugs.dpdk.org/> (raw)

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

https://bugs.dpdk.org/show_bug.cgi?id=1298

            Bug ID: 1298
           Summary: memif disconnect thread vs. rx_burst worker thread(s)
                    crash
           Product: DPDK
           Version: 21.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: bly454@gmail.com
  Target Milestone: ---

Hello,

We have run into a timing issue between threads when using the memif interface
type and need some guidance.

Our application has a DPDK based process operating (among other things) a memif
server interface. The problem is exposed when this memif interface receives a
memif.disconnect message from the remote client, while in the middle of an
rte_eth_rx_burst() on this same memif interface. As the IRQ message handling is
on its own thread as compared to the DPDK worker thread doing the rx_burst,
this resulted in a crash. The backtraces for which have been shared below.

How does one ensure there are guard rails in place to gracefully exit the
rx-burst when a disconnect occurs? Or, how do we properly modify the code such
that  we defer responding to the disconnect CB after the rx-burst operation has
completed?

We are utilizing DPDK 21.11.2. I have diff’d dpdks-stable:22.11.3 in
./drivers/net/memif, but I do not see anything obvious that would address this.
I did a similar diff for dpdk:23.07, but do not see anything obvious there
either.

-Mike

(gdb) thread 1
[Switching to thread 1 (Thread 0x7f17e2813600 (LWP 470))]
#0  0x00007f17e374d225 in eth_memif_rx (queue=0x1189023b00,
bufs=0x7f17e28100e8, nb_pkts=32) at
../git/drivers/net/memif/rte_eth_memif.c:338
338                     last_slot = __atomic_load_n(&ring->head,
__ATOMIC_ACQUIRE);
(gdb) bt
#0  0x00007f17e374d225 in eth_memif_rx (queue=0x1189023b00,
bufs=0x7f17e28100e8, nb_pkts=32) at
../git/drivers/net/memif/rte_eth_memif.c:338
#1  0x000000000047e6fb in rte_eth_rx_burst (nb_pkts=32, rx_pkts=0x7f17e28100e8,
queue_id=0, port_id=<optimized out>) at /usr/include/rte_ethdev.h:5368
#2  pmd_main_loop () at ../git/swfw/api/src/swfwPmd.c:1086
#3  0x000000000047f309 in pmd_launch_one_lcore (dummy=<optimized out>) at
../git/my_process.c:1157
#4  0x00007f17f7070e7c in eal_thread_loop (arg=<optimized out>) at
../git/lib/eal/linux/eal_thread.c:146
#5  0x00007f17f4c3da72 in start_thread (arg=<optimized out>) at
pthread_create.c:442
#6  0x00007f17f4cbf930 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) l
333             ring_size = 1 << mq->log2_ring_size;
334             mask = ring_size - 1;
335
336             if (type == MEMIF_RING_C2S) {
337                     cur_slot = mq->last_head;
338                     last_slot = __atomic_load_n(&ring->head,
__ATOMIC_ACQUIRE);
339             } else {
340                     cur_slot = mq->last_tail;
341                     last_slot = __atomic_load_n(&ring->tail,
__ATOMIC_ACQUIRE);
342             }
(gdb) p ring->head
Cannot access memory at address 0x7f17d8e58006

(gdb) thread 19
[Switching to thread 19 (Thread 0x7f17f0804600 (LWP 468))]
#0  0x00007f17f4caf97b in __GI___close (fd=494) at
../sysdeps/unix/sysv/linux/close.c:27
27        return SYSCALL_CANCEL (close, fd);
(gdb) bt
#0  0x00007f17f4caf97b in __GI___close (fd=494) at
../sysdeps/unix/sysv/linux/close.c:27
#1  0x00007f17e374f01f in memif_free_regions (dev=dev@entry=0x7f17f727f000
<rte_eth_devices+99072>) at ../git/drivers/net/memif/rte_eth_memif.c:882
#2  0x00007f17e37475d0 in memif_disconnect (dev=0x7f17f727f000
<rte_eth_devices+99072>) at ../git/drivers/net/memif/memif_socket.c:623
#3  0x00007f17f7091bd2 in eal_intr_process_interrupts (nfds=<optimized out>,
events=<optimized out>) at ../git/lib/eal/linux/eal_interrupts.c:1026
#4  eal_intr_handle_interrupts (totalfds=<optimized out>, pfd=20) at
../git/lib/eal/linux/eal_interrupts.c:1100
#5  eal_intr_thread_main (arg=<optimized out>) at
../git/lib/eal/linux/eal_interrupts.c:1172
#6  0x00007f17f4c3da72 in start_thread (arg=<optimized out>) at
pthread_create.c:442
#7  0x00007f17f4cbf930 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

                 reply	other threads:[~2023-10-12 15:37 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-1298-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).