From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CFF7145B88; Fri, 25 Oct 2024 23:56:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF7BA4029B; Fri, 25 Oct 2024 23:56:18 +0200 (CEST) Received: from fhigh-a8-smtp.messagingengine.com (fhigh-a8-smtp.messagingengine.com [103.168.172.159]) by mails.dpdk.org (Postfix) with ESMTP id 47D0F4021F for ; Fri, 25 Oct 2024 23:56:17 +0200 (CEST) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id D07BE114012C; Fri, 25 Oct 2024 17:56:16 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Fri, 25 Oct 2024 17:56:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1729893376; x=1729979776; bh=9GVljefpUq+WYCdUC3iAG6vxfjmWHcztVPteqQhamqA=; b= lzqywEszTUZal4sdtx0Ubvsg4JbSdg5ZDLc12cokyEI/2JaTezME9QvBIZfNVTjb EqI3lIm7RT6hYAdkqA93qf1GXgEJdjJjZcvj4Q3g4nEybjmQ+wwRrM4Zv5qb6OgU k4BGey2LZjl7U45g1skI1M6ecL5kl5ihTI0LWrEZJIDjuh8fvWDgqnIalDHYgTVv knyn34V15Uygl47FpgRJQK4I5cunMGsPpnB5nU/gKKCBe97dyIB4ME8y01Qv2HgU 2r6AnpEyOS3WhaLxOSNLTXJA3x3f1nIcrD0p+WpHjRbYXACiRL8U/oobR5LpmhpJ wtSi5fF3Eb7sQud+BKNEYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1729893376; x= 1729979776; bh=9GVljefpUq+WYCdUC3iAG6vxfjmWHcztVPteqQhamqA=; b=D M4YO6KxkpFHBHZe8bV8QD/OVyGWHaUxzHC5aje7lGU+TcLhJu3xk64v6EAbp6GMG FKcxpg6++RiKYh06YugFUi9z1zOEbIbxUmaZWWL/vER7u2hnl/qM0iGXT918sgUx Qr0Nj9AHZpsVq5owZ/Lzt0/PabVeJdbXeFyBjaIyG6JoF7ISjENJLtLwSfKKO8ow t1cB4mroH9nGYLo1Wyvff9zPDZhLBh4PG6Gs56Fr3UVWpO74jhPvX0oB3/bEoTkG 37+3CMTg7v1K467uyXtAafeg1pX6SAG7uwmiGbQjZcXVJUzb0j10STBn/lVo3JsB XMzjyentvHxXqN5KRhEPA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejfedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeffudfgueelhfelleetfefgtefhudei vdegleeifeegtdefueffvedthfefhfduheenucffohhmrghinhepsghoohhtlhhinhdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhnsggprhgtphhtthhopeduuddpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohephhhurghnghguvghnghguuhhisehhuhgrfigv ihdrtghomhdprhgtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrh drohhrghdprhgtphhtthhopeguvghvseguphgukhdrohhrghdprhgtphhtthhopehfvghr rhhuhhdrhihighhithesrghmugdrtghomhdprhgtphhtthhopehmsgesshhmrghrthhshh grrhgvshihshhtvghmshdrtghomhdprhgtphhtthhopegurghvihgurdhmrghrtghhrghn ugesrhgvughhrghtrdgtohhmpdhrtghpthhtohepihgsohhukhhrihhssehgmhgrihhlrd gtohhmpdhrtghpthhtoheplhhihhhuihhsohhngheshhhurgifvghirdgtohhmpdhrtghp thhtohepfhgvnhhgtghhvghnghifvghnsehhuhgrfigvihdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 25 Oct 2024 17:56:14 -0400 (EDT) From: Thomas Monjalon To: huangdengdui Cc: Stephen Hemminger , dev@dpdk.org, ferruh.yigit@amd.com, mb@smartsharesystems.com, david.marchand@redhat.com, iboukris@gmail.com, lihuisong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com, liuyonglong@huawei.com Subject: Re: [PATCH v4 00/42] replace strerror Date: Fri, 25 Oct 2024 23:56:12 +0200 Message-ID: <4609477.bm5RmrZB5H@thomas> In-Reply-To: <56ac151b-79e9-461e-9ace-83af7b602eff@huawei.com> References: <20231114082539.1858594-44-huangdengdui@huawei.com> <20241023084237.4da0ae1b@hermes.local> <56ac151b-79e9-461e-9ace-83af7b602eff@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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.