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 DC6E441D5F; Fri, 24 Feb 2023 16:59:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BB4BE40697; Fri, 24 Feb 2023 16:59:06 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 7145640693 for ; Fri, 24 Feb 2023 16:59:05 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0F9385C0165; Fri, 24 Feb 2023 10:59:05 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute1.internal (MEProxy); Fri, 24 Feb 2023 10:59:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u256.net; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1677254345; x=1677340745; bh=8au1Bi294U 33k7FdvqTUBNgfZL+UAsatzZ0jjdXhZyA=; b=kIQ6B2NUQr5lrRhplGb1p4Ao0g 6uH0Fzm9qKfbyC9RhiFtJ1q4WHugEqmEy1yunX4Ea58WerLZljVucOR1mSmbC3/T 90LEcT+rBDFp8sE/k2GSKocU4fyE/B0CNpyS2o3I0AYmuBbVIA1phKLpEDaD4zop 36J66YVIGF3812V6fjvs7UOSX+9rJalnhI9xr/7We20o+dlAbszRvDAiu8YwskoB a489Zk1Mofgm9wj3hzDe8nzYH9Ve07VxPY9Q9AKfqO1WjVb0FTMFlTxV+GfVHhX4 NR8Zp2pp4EKSZmtIumr/69WDKBHmnugc3fGkXurKVNkRIS3mnia3KMvdGZsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1677254345; x=1677340745; bh=8au1Bi294U33k7FdvqTUBNgfZL+U AsatzZ0jjdXhZyA=; b=fEtqJhGDxnSCqwJ2VA7puYO5Qh+yoOg6BqgbxasZlTha IskzE0IktbWLH8pxxLNsEwJcRlYvggxKd7Oa/tunRDd44Zo8IeuKF9KwU2kByj18 jihaC5aUt6QKBbkxiFeKw/YC6ieqR7nYCEqi4UxeZBgVTc+ZhejT7yt2zJUawQ8x CGDcNcYN2Ov0ShNinURr3Lc+ppLW5ME8VD9S4/GbEVx5b5DZZSIWCFasZXAjsC6N 7Zb7PhtvsTeS0FjG10iuAnCjy8UJRMk5c8eXr9XyqVlOmTrAs50xt+I7pBvDtrrh qeA9cgvaMx7g57lX9sJSrpUOJwBLx3cUN5zv3wDseA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudekfedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderreejnecuhfhrohhmpefirgot thgrnhcutfhivhgvthcuoehgrhhivhgvsehuvdehiedrnhgvtheqnecuggftrfgrthhtvg hrnhepueeigfduvddvleejvefftdffffekjeeiledvleekgeeffeffgffhueefhfejtdek necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrih hvvgesuhdvheeirdhnvght X-ME-Proxy: Feedback-ID: ib851476b:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6A5231A0063; Fri, 24 Feb 2023 10:59:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-172-g9a2dae1853-fm-20230213.001-g9a2dae18 Mime-Version: 1.0 Message-Id: <095511d4-4fbb-47a8-a8a5-f2a3b932c01f@app.fastmail.com> In-Reply-To: <20230224151143.3274897-1-david.marchand@redhat.com> References: <20230224081642.2566619-1-david.marchand@redhat.com> <20230224151143.3274897-1-david.marchand@redhat.com> Date: Fri, 24 Feb 2023 16:58:44 +0100 From: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= To: "David Marchand" , dev@dpdk.org Cc: "Thomas Monjalon" Subject: Re: [PATCH v2 00/20] Enable lock annotations on most libraries and drivers Content-Type: text/plain 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 On Fri, Feb 24, 2023, at 16:11, David Marchand wrote: > This is a followup of the series that introduced lock annotations. > I reworked and made annotations work in what seemed the easier cases. > In most cases, I chose to convert inline wrappers around the EAL lock > API to simple macro: I did not see much value in those wrappers and this > is way simpler than adding __rte_*lock_function tags everywhere. > > A list of libraries and drivers still need more work as their code have > non obvious locks handling. For those components, the check is opted > out. > I leave it to their respective maintainers to enable the checks later. > > FreeBSD libc pthread API has lock annotations while Linux glibc has > none. > We could simply disable the check on FreeBSD, but having this check, > a few issues got raised in drivers that are built with FreeBSD. > For now, I went with a simple #ifdef FreeBSD for pthread mutex related > annotations in our code. > Hi David, This is a great change, thanks for doing it. However I am not sure I understand the logic regarding the '#ifdef FREEBSD'. These annotations provide static hints to clang's thread safety analysis. What is the dependency on FreeBSD glibc? -- Gaetan Rivet