change lspci output decode from ascii to utf-8 #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hello, Sorry, but we don't use pull request through github. Thanks. |
dpdk-replication
force-pushed
the
master
branch
from
a2a485e
to
206b89c
Compare
dpdk-replication
force-pushed
the
master
branch
2 times, most recently
from
ab59484
to
43d0e30
Compare
dpdk-replication
force-pushed
the
master
branch
from
757592a
to
f31d178
Compare
ovsrobot
pushed a commit
to ovsrobot/dpdk
that referenced
this pull request
Nov 10, 2021
the primary program(such as ofp app) run first, then run the secondary program(such as dpdk-pdump), the primary program would receive signal SIGSEGV. the function stack as follow: aived signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee60e700 (LWP 112613)] 0x00007ffff5f2cc0b in bucket_stack_pop (stack=0xffff00010000) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:95 95 if (stack->top == 0) Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64 libatomic-4.8.5-16.el7.x86_64 libconfig-1.4.9-5.el7.x86_64 libgcc-4.8.5-16.el7.x86_64 libpcap-1.5.3-12.el7.x86_64 numactl-libs-2.0.9-6.el7_2.x86_64 openssl-libs-1.0.2k-8.el7.x86_64 zlib-1.2.7-17.el7.x86_64 (gdb) bt #0 0x00007ffff5f2cc0b in bucket_stack_pop (stack=0xffff00010000) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:95 DPDK#1 0x00007ffff5f2e5dc in bucket_dequeue_orphans (bd=0x2209e5fac0,obj_table=0x220b083710, n_orphans=251) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:190 DPDK#2 0x00007ffff5f30192 in bucket_dequeue (mp=0x220b07d5c0,obj_table=0x220b083710, n=251) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:288 DPDK#3 0x00007ffff5f47e18 in rte_mempool_ops_dequeue_bulk (mp=0x220b07d5c0,obj_table=0x220b083710, n=251) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:739 DPDK#4 0x00007ffff5f4819d in __mempool_generic_get (cache=0x220b083700, n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1443 DPDK#5 rte_mempool_generic_get (cache=0x220b083700, n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1506 DPDK#6 rte_mempool_get_bulk (n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1539 DPDK#7 rte_mempool_get (obj_p=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1565 DPDK#8 rte_mbuf_raw_alloc (mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:551 DPDK#9 0x00007ffff5f483a4 in rte_pktmbuf_alloc (mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:804 DPDK#10 0x00007ffff5f4c9d9 in pdump_pktmbuf_copy (m=0x220746ad80, mp=0x220b07d5c0) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:99 DPDK#11 0x00007ffff5f4e42e in pdump_copy (pkts=0x7fffee5dfdf0, nb_pkts=1, user_params=0x7ffff76d7cc0 <rx_cbs>) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:151 DPDK#12 0x00007ffff5f4eadd in pdump_rx (port=0, qidx=0, pkts=0x7fffee5dfdf0, nb_pkts=1, max_pkts=16, user_params=0x7ffff76d7cc0 <rx_cbs>) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:172 DPDK#13 0x00007ffff5d0e9e8 in rte_eth_rx_burst (port_id=0, queue_id=0, rx_pkts=0x7fffee5dfdf0, nb_pkts=16) at /ofp/dpdk/x86_64-native-linuxapp-gcc/usr/local/include/dpdk/rte_ethdev.h:4396 DPDK#14 0x00007ffff5d114c3 in recv_pkt_dpdk (pktio_entry=0x22005436c0, index=0, pkt_table=0x7fffee5dfdf0, num=16) at odp_packet_dpdk.c:1081 DPDK#15 0x00007ffff5d2f931 in odp_pktin_recv (queue=...,packets=0x7fffee5dfdf0, num=16) at ../linux-generic/odp_packet_io.c:1896 DPDK#16 0x000000000040a344 in rx_burst (pktin=...) at app_main.c:223 DPDK#17 0x000000000040aca4 in run_server_single (arg=0x7fffffffe2b0) at app_main.c:417 DPDK#18 0x00007ffff7bd6883 in run_thread (arg=0x7fffffffe3b8) at threads.c:67 DPDK#19 0x00007ffff53c8e25 in start_thread () from /lib64/libpthread.so.0 DPDK#20 0x00007ffff433e34d in clone () from /lib64/libc.so.6.c:67 The program crash down reason is: In primary program and secondary program , the global array rte_mempool_ops.ops[]: primary name secondary name [0]: "bucket" "ring_mp_mc" [1]: "dpaa" "ring_sp_sc" [2]: "dpaa2" "ring_mp_sc" [3]: "octeontx_fpavf" "ring_sp_mc" [4]: "octeontx2_npa" "octeontx2_npa" [5]: "ring_mp_mc" "bucket" [6]: "ring_sp_sc" "stack" [7]: "ring_mp_sc" "if_stack" [8]: "ring_sp_mc" "dpaa" [9]: "stack" "dpaa2" [10]: "if_stack" "octeontx_fpavf" [11]: NULL NULL this array in primary program is different with secondary program. so when secondary program call rte_pktmbuf_pool_create_by_ops() with mempool name “ring_mp_mc”, but the primary program use "bucket" type to alloc rte_mbuf. so sort this array both primary program and secondary program when init memzone. Signed-off-by: Tianli Lai <laitianli@tom.com> Signed-off-by: 0-day Robot <robot@bytheb.org>
laitianli
added a commit
to laitianli/dpdk
that referenced
this pull request
Nov 20, 2021
the primary program(such as ofp app) run first, then run the secondary program(such as dpdk-pdump), the primary program would receive signal SIGSEGV. the function stack as follow: aived signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee60e700 (LWP 112613)] 0x00007ffff5f2cc0b in bucket_stack_pop (stack=0xffff00010000) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:95 95 if (stack->top == 0) Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64 libatomic-4.8.5-16.el7.x86_64 libconfig-1.4.9-5.el7.x86_64 libgcc-4.8.5-16.el7.x86_64 libpcap-1.5.3-12.el7.x86_64 numactl-libs-2.0.9-6.el7_2.x86_64 openssl-libs-1.0.2k-8.el7.x86_64 zlib-1.2.7-17.el7.x86_64 (gdb) bt #0 0x00007ffff5f2cc0b in bucket_stack_pop (stack=0xffff00010000) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:95 DPDK#1 0x00007ffff5f2e5dc in bucket_dequeue_orphans (bd=0x2209e5fac0,obj_table=0x220b083710, n_orphans=251) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:190 DPDK#2 0x00007ffff5f30192 in bucket_dequeue (mp=0x220b07d5c0,obj_table=0x220b083710, n=251) at /ofp/dpdk/drivers/mempool/bucket/rte_mempool_bucket.c:288 DPDK#3 0x00007ffff5f47e18 in rte_mempool_ops_dequeue_bulk (mp=0x220b07d5c0,obj_table=0x220b083710, n=251) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:739 DPDK#4 0x00007ffff5f4819d in __mempool_generic_get (cache=0x220b083700, n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1443 DPDK#5 rte_mempool_generic_get (cache=0x220b083700, n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1506 DPDK#6 rte_mempool_get_bulk (n=1, obj_table=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1539 DPDK#7 rte_mempool_get (obj_p=0x7fffee5deb18, mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1565 DPDK#8 rte_mbuf_raw_alloc (mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:551 DPDK#9 0x00007ffff5f483a4 in rte_pktmbuf_alloc (mp=0x220b07d5c0) at /ofp/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:804 DPDK#10 0x00007ffff5f4c9d9 in pdump_pktmbuf_copy (m=0x220746ad80, mp=0x220b07d5c0) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:99 DPDK#11 0x00007ffff5f4e42e in pdump_copy (pkts=0x7fffee5dfdf0, nb_pkts=1, user_params=0x7ffff76d7cc0 <rx_cbs>) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:151 DPDK#12 0x00007ffff5f4eadd in pdump_rx (port=0, qidx=0, pkts=0x7fffee5dfdf0, nb_pkts=1, max_pkts=16, user_params=0x7ffff76d7cc0 <rx_cbs>) at /ofp/dpdk/lib/librte_pdump/rte_pdump.c:172 DPDK#13 0x00007ffff5d0e9e8 in rte_eth_rx_burst (port_id=0, queue_id=0, rx_pkts=0x7fffee5dfdf0, nb_pkts=16) at /ofp/dpdk/x86_64-native-linuxapp-gcc/usr/local/include/dpdk/rte_ethdev.h:4396 DPDK#14 0x00007ffff5d114c3 in recv_pkt_dpdk (pktio_entry=0x22005436c0, index=0, pkt_table=0x7fffee5dfdf0, num=16) at odp_packet_dpdk.c:1081 DPDK#15 0x00007ffff5d2f931 in odp_pktin_recv (queue=...,packets=0x7fffee5dfdf0, num=16) at ../linux-generic/odp_packet_io.c:1896 DPDK#16 0x000000000040a344 in rx_burst (pktin=...) at app_main.c:223 DPDK#17 0x000000000040aca4 in run_server_single (arg=0x7fffffffe2b0) at app_main.c:417 DPDK#18 0x00007ffff7bd6883 in run_thread (arg=0x7fffffffe3b8) at threads.c:67 DPDK#19 0x00007ffff53c8e25 in start_thread () from /lib64/libpthread.so.0 DPDK#20 0x00007ffff433e34d in clone () from /lib64/libc.so.6.c:67 The program crash down reason is: In primary program and secondary program , the global array rte_mempool_ops.ops[]: primary name secondary name [0]: "bucket" "ring_mp_mc" [1]: "dpaa" "ring_sp_sc" [2]: "dpaa2" "ring_mp_sc" [3]: "octeontx_fpavf" "ring_sp_mc" [4]: "octeontx2_npa" "octeontx2_npa" [5]: "ring_mp_mc" "bucket" [6]: "ring_sp_sc" "stack" [7]: "ring_mp_sc" "if_stack" [8]: "ring_sp_mc" "dpaa" [9]: "stack" "dpaa2" [10]: "if_stack" "octeontx_fpavf" [11]: NULL NULL this array in primary program is different with secondary program. so when secondary program call rte_pktmbuf_pool_create_by_ops() with mempool name “ring_mp_mc”, but the primary program use "bucket" type to alloc rte_mbuf. so sort this array both primary program and secondary program when init memzone. Signed-off-by: Tianli Lai <laitianli@tom.com>
ovsrobot
pushed a commit
to ovsrobot/dpdk
that referenced
this pull request
Aug 1, 2023
getline() may allocate a buffer even though it returns -1:
"""
If *lineptr is set to NULL before the call, then getline() will allocate
a buffer for storing the line. This buffer should be freed by the user
program even if getline() failed.
"""
This leak has been observed on a RHEL8 system with two CX5 PF devices
(no VFs).
ASan reports:
==8899==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x7fe58576aba8 in __interceptor_malloc
(/lib64/libasan.so.5+0xefba8)
DPDK#1 0x7fe583e866b2 in __getdelim (/lib64/libc.so.6+0x886b2)
DPDK#2 0x327bd23 in mlx5_sysfs_switch_info
../drivers/net/mlx5/linux/mlx5_ethdev_os.c:1084
DPDK#3 0x3271f86 in mlx5_os_pci_probe_pf
../drivers/net/mlx5/linux/mlx5_os.c:2282
DPDK#4 0x3273c83 in mlx5_os_pci_probe
../drivers/net/mlx5/linux/mlx5_os.c:2497
DPDK#5 0x327475f in mlx5_os_net_probe
../drivers/net/mlx5/linux/mlx5_os.c:2578
DPDK#6 0xc6eac7 in drivers_probe
../drivers/common/mlx5/mlx5_common.c:937
DPDK#7 0xc6f150 in mlx5_common_dev_probe
../drivers/common/mlx5/mlx5_common.c:1027
DPDK#8 0xc8ef80 in mlx5_common_pci_probe
../drivers/common/mlx5/mlx5_common_pci.c:168
DPDK#9 0xc21b67 in rte_pci_probe_one_driver
../drivers/bus/pci/pci_common.c:312
DPDK#10 0xc2224c in pci_probe_all_drivers
../drivers/bus/pci/pci_common.c:396
DPDK#11 0xc222f4 in pci_probe ../drivers/bus/pci/pci_common.c:423
DPDK#12 0xb71fff in rte_bus_probe ../lib/eal/common/eal_common_bus.c:78
DPDK#13 0xbe6888 in rte_eal_init ../lib/eal/linux/eal.c:1300
DPDK#14 0x5ec717 in main ../app/test-pmd/testpmd.c:4515
DPDK#15 0x7fe583e38d84 in __libc_start_main (/lib64/libc.so.6+0x3ad84)
As far as why getline() errors, strace gives a hint:
8516 openat(AT_FDCWD, "/sys/class/net/enp130s0f0/phys_port_name",
O_RDONLY) = 34
8516 fstat(34, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
8516 read(34, 0x621000098900, 4096) = -1 EOPNOTSUPP (Operation
not supported)
Fixes: f8a226e ("net/mlx5: fix sysfs port name translation")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
david-marchand
added a commit
to david-marchand/dpdk
that referenced
this pull request
Sep 5, 2023
getline() may allocate a buffer even though it returns -1:
"""
If *lineptr is set to NULL before the call, then getline() will allocate
a buffer for storing the line. This buffer should be freed by the user
program even if getline() failed.
"""
This leak has been observed on a RHEL8 system with two CX5 PF devices
(no VFs).
ASan reports:
==8899==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x7fe58576aba8 in __interceptor_malloc
(/lib64/libasan.so.5+0xefba8)
DPDK#1 0x7fe583e866b2 in __getdelim (/lib64/libc.so.6+0x886b2)
DPDK#2 0x327bd23 in mlx5_sysfs_switch_info
../drivers/net/mlx5/linux/mlx5_ethdev_os.c:1084
DPDK#3 0x3271f86 in mlx5_os_pci_probe_pf
../drivers/net/mlx5/linux/mlx5_os.c:2282
DPDK#4 0x3273c83 in mlx5_os_pci_probe
../drivers/net/mlx5/linux/mlx5_os.c:2497
DPDK#5 0x327475f in mlx5_os_net_probe
../drivers/net/mlx5/linux/mlx5_os.c:2578
DPDK#6 0xc6eac7 in drivers_probe
../drivers/common/mlx5/mlx5_common.c:937
DPDK#7 0xc6f150 in mlx5_common_dev_probe
../drivers/common/mlx5/mlx5_common.c:1027
DPDK#8 0xc8ef80 in mlx5_common_pci_probe
../drivers/common/mlx5/mlx5_common_pci.c:168
DPDK#9 0xc21b67 in rte_pci_probe_one_driver
../drivers/bus/pci/pci_common.c:312
DPDK#10 0xc2224c in pci_probe_all_drivers
../drivers/bus/pci/pci_common.c:396
DPDK#11 0xc222f4 in pci_probe ../drivers/bus/pci/pci_common.c:423
DPDK#12 0xb71fff in rte_bus_probe ../lib/eal/common/eal_common_bus.c:78
DPDK#13 0xbe6888 in rte_eal_init ../lib/eal/linux/eal.c:1300
DPDK#14 0x5ec717 in main ../app/test-pmd/testpmd.c:4515
DPDK#15 0x7fe583e38d84 in __libc_start_main (/lib64/libc.so.6+0x3ad84)
As far as why getline() errors, strace gives a hint:
8516 openat(AT_FDCWD, "/sys/class/net/enp130s0f0/phys_port_name",
O_RDONLY) = 34
8516 fstat(34, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
8516 read(34, 0x621000098900, 4096) = -1 EOPNOTSUPP (Operation
not supported)
Fixes: f8a226e ("net/mlx5: fix sysfs port name translation")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
dpdk-replication
pushed a commit
that referenced
this pull request
Oct 16, 2023
getline() may allocate a buffer even though it returns -1:
"""
If *lineptr is set to NULL before the call, then getline() will allocate
a buffer for storing the line. This buffer should be freed by the user
program even if getline() failed.
"""
This leak has been observed on a RHEL8 system with two CX5 PF devices
(no VFs).
ASan reports:
==8899==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x7fe58576aba8 in __interceptor_malloc
(/lib64/libasan.so.5+0xefba8)
#1 0x7fe583e866b2 in __getdelim (/lib64/libc.so.6+0x886b2)
#2 0x327bd23 in mlx5_sysfs_switch_info
../drivers/net/mlx5/linux/mlx5_ethdev_os.c:1084
#3 0x3271f86 in mlx5_os_pci_probe_pf
../drivers/net/mlx5/linux/mlx5_os.c:2282
#4 0x3273c83 in mlx5_os_pci_probe
../drivers/net/mlx5/linux/mlx5_os.c:2497
#5 0x327475f in mlx5_os_net_probe
../drivers/net/mlx5/linux/mlx5_os.c:2578
#6 0xc6eac7 in drivers_probe
../drivers/common/mlx5/mlx5_common.c:937
#7 0xc6f150 in mlx5_common_dev_probe
../drivers/common/mlx5/mlx5_common.c:1027
#8 0xc8ef80 in mlx5_common_pci_probe
../drivers/common/mlx5/mlx5_common_pci.c:168
#9 0xc21b67 in rte_pci_probe_one_driver
../drivers/bus/pci/pci_common.c:312
#10 0xc2224c in pci_probe_all_drivers
../drivers/bus/pci/pci_common.c:396
#11 0xc222f4 in pci_probe ../drivers/bus/pci/pci_common.c:423
#12 0xb71fff in rte_bus_probe ../lib/eal/common/eal_common_bus.c:78
#13 0xbe6888 in rte_eal_init ../lib/eal/linux/eal.c:1300
#14 0x5ec717 in main ../app/test-pmd/testpmd.c:4515
#15 0x7fe583e38d84 in __libc_start_main (/lib64/libc.so.6+0x3ad84)
As far as why getline() errors, strace gives a hint:
8516 openat(AT_FDCWD, "/sys/class/net/enp130s0f0/phys_port_name",
O_RDONLY) = 34
8516 fstat(34, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
8516 read(34, 0x621000098900, 4096) = -1 EOPNOTSUPP (Operation
not supported)
Fixes: f8a226e ("net/mlx5: fix sysfs port name translation")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
lspci output may contain utf-8 character, and this cause dpdk-devbind to fail. For example:
root# lspci -vmmks 0000:af:00.0
Slot: af:00.0
Class: Ethernet controller
Vendor: Mellanox Technologies
Device: MT27800 Family [ConnectX-5]
SVendor: Mellanox Technologies
SDevice: ConnectX®-5 EN network interface card, 100GbE single-port QSFP28, PCIe3.0 x16, tall bracket; MCX515A-CCAT
Driver: mlx5_core
lspci: Unable to load libkmod resources: error -12
NUMANode: 1
root# dpdk-devbind -s
lspci: Unable to load libkmod resources: error -12
Traceback (most recent call last):
File "/usr/local/bin/dpdk-devbind", line 741, in
main()
File "/usr/local/bin/dpdk-devbind", line 731, in main
get_device_details(network_devices)
File "/usr/local/bin/dpdk-devbind", line 257, in get_device_details
name, value = dev_line.decode().split("\t", 1)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 17: ordinal not in range(128)
change to str decode from the default ascii to 'utf-8' shall solve this issue.