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 6249D4241C; Thu, 19 Jan 2023 20:43:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 53C9B4067E; Thu, 19 Jan 2023 20:43:23 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 7D0F540223 for ; Thu, 19 Jan 2023 20:43:22 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id b10so3456324pjo.1 for ; Thu, 19 Jan 2023 11:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=l9PRvt2C9X35X503qbDnHlPIb5MzBpnRm+4ghfWTNs8=; b=1pfU3NraAoHfRe0/W8UdtqPGT4lSV38064jAMwa4ttsS8DRRFwkDlT600IXEpPL+KO xmsU+qEYUQ+FRenrcypq5/c3RuGuy1hvLy+Sz5gl0Pk9xPFjKoLXEtx0+H50AQvxtdpE nTw8nmnLdTmpuFWx+B5bIAokvDxKgOz5DJ6+uGbl7LWrWunk980H+5JNiOAiyUGyxf5j gmoYK+Eu7cT3/ozPQ4iCVcaT8ecUaQ62e8zc+coOMf23DIPuPDoB/v2DmdcyBvoFn0ZC jVw8jphZrhqZ+iOfxwFQW3E2owl78BwqqASpLEvWSIqY5nBIQo4Bm2Mt1e9AgkRMCp8i bQvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l9PRvt2C9X35X503qbDnHlPIb5MzBpnRm+4ghfWTNs8=; b=T0UPZtWbGX8pdkatdie0QAbG+/XnZ72TdVcoxbDUi37DNww6Vk8VdczDSwAiSiyLfA 3bs1Lap2zSFSVm7Kww27rdb44rxzrV1MtLrIaLajuDphYtAazcFmJF/9vp6on6CWEVTi Ln1CNgoO55YNojjS5ohFw1n5Hcb9oQ52AWXlt7v6wgudKiJescKGuqvvmjdQk5hHozvb R35FLwaLxqhPPQOxeznxWkWn2qvhQc4am9gU+MtjyIdukc17ZLXxF/l4b7MT9n6MJIxO 0FdNhSRvpg7M5sxO+U+p5C+a8OxhV8NmHxVOUdFcyYdDbEc8SsXGMdIQ62ka4cpJpiGh +utA== X-Gm-Message-State: AFqh2kpBhoAByKLQ5ctoCglR805ptsoQ2yBgArXC42dv2ImYnJUZ9w4j csK6QqjxV47ToYWBpMZ4wOVuMw== X-Google-Smtp-Source: AMrXdXuOTxov869p84DEXj9n7U+JQLFqlzFZh4A+pGyKxApaDoMhCN7mO9bT8YiIPlgJFKJ51U3nuA== X-Received: by 2002:a17:90a:3fca:b0:227:161a:6318 with SMTP id u10-20020a17090a3fca00b00227161a6318mr12098286pjm.47.1674157401625; Thu, 19 Jan 2023 11:43:21 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id l7-20020a17090a150700b002296bffb667sm4344pja.45.2023.01.19.11.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 11:43:21 -0800 (PST) Date: Thu, 19 Jan 2023 11:43:19 -0800 From: Stephen Hemminger To: David Marchand Cc: dev@dpdk.org, maxime.coquelin@redhat.com, chenbo.xia@intel.com, jiayu.hu@intel.com, yuanx.wang@intel.com, xuan.ding@intel.com, Anatoly Burakov , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , David Christensen , Bruce Richardson , Konstantin Ananyev Subject: Re: [PATCH v4 1/9] eal: annotate spinlock, rwlock and seqlock Message-ID: <20230119114319.109a6c73@hermes.local> In-Reply-To: <20230119184620.3195267-2-david.marchand@redhat.com> References: <20220328121758.26632-1-david.marchand@redhat.com> <20230119184620.3195267-1-david.marchand@redhat.com> <20230119184620.3195267-2-david.marchand@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Thu, 19 Jan 2023 19:46:12 +0100 David Marchand wrote: > clang offers some thread safety checks, statically verifying that locks > are taken and released in the code. > To use those checks, the full code leading to taking or releasing locks > must be annotated with some attributes. > > Wrap those attributes into our own set of macros. > > rwlock, seqlock and the "normal" spinlock are instrumented. > > Those checks might be of interest out of DPDK, but it requires that the > including application locks are annotated. > On the other hand, applications out there might have been using > those same checks. > To be on the safe side, keep this instrumentation under a > RTE_ANNOTATE_LOCKS internal build flag. > > A component may en/disable this check by setting > annotate_locks = true/false in its meson.build. Could this be made to work with sparse as well?