Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
I used ovs in the vxlan mode.
(gdb) bt
#0 0x00007f4f027ae5d7 in raise () from /lib64/libc.so.6
#1 0x00007f4f027afcc8 in abort () from /lib64/libc.so.6
#2 0x0000555b0eeea2a5 in xlate_push_stats (xcache=<optimized out>, may_learn=true, stats=stats@entry=0x7f4ef4ff6b50)
at ofproto/ofproto-dpif-xlate.c:3674
#3 0x0000555b0eee1d69 in revalidate_ukey (udpif=udpif@entry=0x555b10f404c0, ukey=ukey@entry=0x7f4edc029880,
mask=0x7f4eb00348c4, mask_len=192, actions=0x7f4eb00349a8, actions_len=0, stats=0x7f4eb00118c0)
at ofproto/ofproto-dpif-upcall.c:1261
#4 0x0000555b0eee2819 in revalidate (revalidator=0x555b10f70d80) at ofproto/ofproto-dpif-upcall.c:1503
#5 0x0000555b0eee2eeb in udpif_revalidator (arg=0x555b10f70d80) at ofproto/ofproto-dpif-upcall.c:592
#6 0x0000555b0ef4cad3 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs-thread.c:322
#7 0x00007f4f0304bdf5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f4f0286f1ad in clone () from /lib64/libc.so.6
(gdb) f 3
#3 0x0000555b0eee1d69 in revalidate_ukey (udpif=udpif@entry=0x555b10f404c0, ukey=ukey@entry=0x7f4edc029880,
mask=0x7f4eb00348c4, mask_len=192, actions=0x7f4eb00349a8, actions_len=0, stats=0x7f4eb00118c0)
at ofproto/ofproto-dpif-upcall.c:1261
1261 xlate_push_stats(ukey->xcache, may_learn, &push);
(gdb) p ukey->xcache
$1 = (struct xlate_cache *) 0x7f4e8c026e80
(gdb) p push
$2 = {n_packets = 1, n_bytes = 42, used = 15288297083, tcp_flags = 0}
(gdb) p ukey->xcache->entries
$3 = {base_ = 0x7f4e8c00ed50, data_ = 0x7f4e8c00ed50, size_ = 96, allocated = 512, frame = 0x0, l2_5_ofs = 65535,
l3_ofs = 65535, l4_ofs = 65535, source = OFPBUF_MALLOC, list_node = {prev = 0xcccccccccccccccc,
next = 0xcccccccccccccccc}}
(gdb) f 2
#2 0x0000555b0eeea2a5 in xlate_push_stats (xcache=<optimized out>, may_learn=true, stats=stats@entry=0x7f4ef4ff6b50)
at ofproto/ofproto-dpif-xlate.c:3674
3674 OVS_NOT_REACHED();
(gdb) p entry->type
$4 = 3815977278
On other nodes:
#0 0x00007f16b5ee25d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-78.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.12.2-14.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.1e-42.el7.x86_64 pcre-8.32-14.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64
(gdb) bt
#0 0x00007f16b5ee25d7 in raise () from /lib64/libc.so.6
#1 0x00007f16b5ee3cc8 in abort () from /lib64/libc.so.6
#2 0x000055efe64ee435 in xlate_cache_clear (xcache=0x7f16ac008c90) at ofproto/ofproto-dpif-xlate.c:3741
#3 0x000055efe64e5dd4 in revalidate_ukey (udpif=udpif@entry=0x55efe751d400, ukey=ukey@entry=0x7f16ac005da0, mask=0x7f16ac02018c, mask_len=180, actions=0x7f16ac020264,
actions_len=0, stats=0x7f16ac001000) at ofproto/ofproto-dpif-upcall.c:1273
#4 0x000055efe64e6819 in revalidate (revalidator=0x55efe7525180) at ofproto/ofproto-dpif-upcall.c:1503
#5 0x000055efe64e6eeb in udpif_revalidator (arg=0x55efe7525180) at ofproto/ofproto-dpif-upcall.c:592
#6 0x000055efe6550ad3 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs-thread.c:322
#7 0x00007f16b677fdf5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f16b5fa31ad in clone () from /lib64/libc.so.6
(gdb) f 2
#2 0x000055efe64ee435 in xlate_cache_clear (xcache=0x7f16ac008c90) at ofproto/ofproto-dpif-xlate.c:3741
3741 OVS_NOT_REACHED();
(gdb) p entry->type
$1 = 858188606
(gdb) p *entry
$2 = {type = 858188606, u = {rule = 0x55efe763b690, dev = {tx = 0x55efe763b690, rx = 0x0, bfd = 0x0}, nf = {netflow = 0x55efe763b690, flow = 0x0, iface = 0}, mirror = {
mbridge = 0x55efe763b690, mirrors = 0}, bond = {bond = 0x55efe763b690, flow = 0x0, vid = 0}, learn = {ofproto = 0x55efe763b690, fm = 0x0, ofpacts = 0x0},
normal = {ofproto = 0x55efe763b690, flow = 0x0, vlan = 0}, fin = {rule = 0x55efe763b690, idle = 0, hard = 0}}}
(gdb)
as the up backtrace what confused me is that
entry->type is not correct, I don't known how to reproduce it.
It looks like the threads didn't do well with the xcache
Version-Release number of selected component (if applicable):
openvswitch:2.3.1
linux kernel:4.4.110
How reproducible:
don't known how to reproduce
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Hi Yogazhao,
Unfortunately, this BZ cannot be serviced in its current form.
Version-Release number of selected component (if applicable):
openvswitch:2.3.1
linux kernel:4.4.110
How reproducible:
don't known how to reproduce
OVS 2.3.1 with 4.4.110 kernel is not a supported combination.
Currently we are supporting OVS with our layered products OSP, OSE, or RHV and they are not using this combination
Plus you mention the issues is not reproducible.
Can I request you to please work with our customer support team and file an official ticket with them. And they can guide you further.
Thanks
If I am missing something please do let me know, and we will try to look at it again
Description of problem: I used ovs in the vxlan mode. (gdb) bt #0 0x00007f4f027ae5d7 in raise () from /lib64/libc.so.6 #1 0x00007f4f027afcc8 in abort () from /lib64/libc.so.6 #2 0x0000555b0eeea2a5 in xlate_push_stats (xcache=<optimized out>, may_learn=true, stats=stats@entry=0x7f4ef4ff6b50) at ofproto/ofproto-dpif-xlate.c:3674 #3 0x0000555b0eee1d69 in revalidate_ukey (udpif=udpif@entry=0x555b10f404c0, ukey=ukey@entry=0x7f4edc029880, mask=0x7f4eb00348c4, mask_len=192, actions=0x7f4eb00349a8, actions_len=0, stats=0x7f4eb00118c0) at ofproto/ofproto-dpif-upcall.c:1261 #4 0x0000555b0eee2819 in revalidate (revalidator=0x555b10f70d80) at ofproto/ofproto-dpif-upcall.c:1503 #5 0x0000555b0eee2eeb in udpif_revalidator (arg=0x555b10f70d80) at ofproto/ofproto-dpif-upcall.c:592 #6 0x0000555b0ef4cad3 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs-thread.c:322 #7 0x00007f4f0304bdf5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f4f0286f1ad in clone () from /lib64/libc.so.6 (gdb) f 3 #3 0x0000555b0eee1d69 in revalidate_ukey (udpif=udpif@entry=0x555b10f404c0, ukey=ukey@entry=0x7f4edc029880, mask=0x7f4eb00348c4, mask_len=192, actions=0x7f4eb00349a8, actions_len=0, stats=0x7f4eb00118c0) at ofproto/ofproto-dpif-upcall.c:1261 1261 xlate_push_stats(ukey->xcache, may_learn, &push); (gdb) p ukey->xcache $1 = (struct xlate_cache *) 0x7f4e8c026e80 (gdb) p push $2 = {n_packets = 1, n_bytes = 42, used = 15288297083, tcp_flags = 0} (gdb) p ukey->xcache->entries $3 = {base_ = 0x7f4e8c00ed50, data_ = 0x7f4e8c00ed50, size_ = 96, allocated = 512, frame = 0x0, l2_5_ofs = 65535, l3_ofs = 65535, l4_ofs = 65535, source = OFPBUF_MALLOC, list_node = {prev = 0xcccccccccccccccc, next = 0xcccccccccccccccc}} (gdb) f 2 #2 0x0000555b0eeea2a5 in xlate_push_stats (xcache=<optimized out>, may_learn=true, stats=stats@entry=0x7f4ef4ff6b50) at ofproto/ofproto-dpif-xlate.c:3674 3674 OVS_NOT_REACHED(); (gdb) p entry->type $4 = 3815977278 On other nodes: #0 0x00007f16b5ee25d7 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-78.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.12.2-14.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.1e-42.el7.x86_64 pcre-8.32-14.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64 (gdb) bt #0 0x00007f16b5ee25d7 in raise () from /lib64/libc.so.6 #1 0x00007f16b5ee3cc8 in abort () from /lib64/libc.so.6 #2 0x000055efe64ee435 in xlate_cache_clear (xcache=0x7f16ac008c90) at ofproto/ofproto-dpif-xlate.c:3741 #3 0x000055efe64e5dd4 in revalidate_ukey (udpif=udpif@entry=0x55efe751d400, ukey=ukey@entry=0x7f16ac005da0, mask=0x7f16ac02018c, mask_len=180, actions=0x7f16ac020264, actions_len=0, stats=0x7f16ac001000) at ofproto/ofproto-dpif-upcall.c:1273 #4 0x000055efe64e6819 in revalidate (revalidator=0x55efe7525180) at ofproto/ofproto-dpif-upcall.c:1503 #5 0x000055efe64e6eeb in udpif_revalidator (arg=0x55efe7525180) at ofproto/ofproto-dpif-upcall.c:592 #6 0x000055efe6550ad3 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs-thread.c:322 #7 0x00007f16b677fdf5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f16b5fa31ad in clone () from /lib64/libc.so.6 (gdb) f 2 #2 0x000055efe64ee435 in xlate_cache_clear (xcache=0x7f16ac008c90) at ofproto/ofproto-dpif-xlate.c:3741 3741 OVS_NOT_REACHED(); (gdb) p entry->type $1 = 858188606 (gdb) p *entry $2 = {type = 858188606, u = {rule = 0x55efe763b690, dev = {tx = 0x55efe763b690, rx = 0x0, bfd = 0x0}, nf = {netflow = 0x55efe763b690, flow = 0x0, iface = 0}, mirror = { mbridge = 0x55efe763b690, mirrors = 0}, bond = {bond = 0x55efe763b690, flow = 0x0, vid = 0}, learn = {ofproto = 0x55efe763b690, fm = 0x0, ofpacts = 0x0}, normal = {ofproto = 0x55efe763b690, flow = 0x0, vlan = 0}, fin = {rule = 0x55efe763b690, idle = 0, hard = 0}}} (gdb) as the up backtrace what confused me is that entry->type is not correct, I don't known how to reproduce it. It looks like the threads didn't do well with the xcache Version-Release number of selected component (if applicable): openvswitch:2.3.1 linux kernel:4.4.110 How reproducible: don't known how to reproduce Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: