On 2024/10/26 5:56, Thomas Monjalon wrote: > 24/10/2024 08:47, huangdengdui: >> On 2024/10/23 23:42, Stephen Hemminger wrote: >>> On Wed, 23 Oct 2024 16:28:10 +0800 >>> Dengdui Huang <huangdeng...@huawei.com> wrote: >>> >>>> The function strerror() is insecure in a multi-thread environment. >>>> It is better to use rte_strerror() instead of strerror(). >>>> In this patchset, only the libs and drivers are modified. >>> >>> Even rte_strerror is not completely safe. It depends on the calling >>> thread being a registered lcore. >> >> As discussed earlier, it is still safe if used from non-DPDK registered >> threads[1]: >> >> #define RTE_DEFINE_PER_LCORE(type, name) \ >> __thread __typeof__(type) per_lcore_##name >> >> [1]: >> https://elixir.bootlin.com/dpdk/v23.11-rc3/source/lib/eal/include/rte_per_lcore.h#L37 >> >>> >>> It would be better to use a coccinelle script to do direct replacement >>> with strerror_r(). >>> >>> Also, rte_strerror is not signal safe. >> >> Can we use strerror_r() in the signal processing context and replace it with >> rte_strerror() everywhere else? > > It does not make sense to use rte_strerror after libc functions. > Please restrict the use of rte_strerror for error numbers from DPDK functions. > >
The Windows platform does not support strerror_r(). Using strerror_r() instead of strerror() is not a good idea, Platform differences have been handled in rte_strerror()[1]. The rte_strerror() can also handle errno from libc functions[2][3]. So is it better to use rte_strerror() instead of strerror()? [1]https://elixir.bootlin.com/dpdk/v23.11-rc3/source/lib/eal/common/eal_common_errno.c#L15 [2]https://elixir.bootlin.com/dpdk/v23.11-rc3/source/lib/eal/common/eal_common_errno.c#L49 [3]https://elixir.bootlin.com/dpdk/v23.11-rc3/source/lib/eal/include/rte_errno.h#L32
