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 E854145E03; Mon, 2 Dec 2024 13:53:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BCF8840270; Mon, 2 Dec 2024 13:53:37 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 61ED5400D6 for ; Mon, 2 Dec 2024 13:53:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733144016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=CbFH6gry/EInGmfnnHko2Bhv0j0lsyeY/ZwCwil6Kko=; b=GmOTUmKYAN2yGgKDNEyEuxja4UW87dxeKYSC1yRmEuIsQoXwN8s5joZG+qEnFixgjZneuN lCokcD7DwasH2V+7TQZb2ybCb2OnyfBh3EuBe7nKNHKhuD1nhWk1PRuqcK8eF7GHKTGKrR AM8p0bTy40Z7xWpMEN2CRR4gTUlnMSc= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-177-dAlRkdCrNRSwfMk__ZxWKw-1; Mon, 02 Dec 2024 07:53:34 -0500 X-MC-Unique: dAlRkdCrNRSwfMk__ZxWKw-1 X-Mimecast-MFC-AGG-ID: dAlRkdCrNRSwfMk__ZxWKw Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C3B771944DC4; Mon, 2 Dec 2024 12:53:33 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.225.129]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 76CC51955E98; Mon, 2 Dec 2024 12:53:32 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: thomas@monjalon.net Subject: [RFC 0/3] Improve lock annotations Date: Mon, 2 Dec 2024 13:53:13 +0100 Message-ID: <20241202125316.3732529-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gbtqob5pNb00OEEU1M5amJMrW2lU_uivtG5bqCSm-Rk_1733144014 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true 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 A recent bug (see 22aa9a9c7099 ("vhost: fix deadlock in Rx async path")) made more visible a gap in the clang thread safety annotations that DPDK uses: no distinction is made between releasing a read lock and releasing a write lock. Clang 3.6 and later offers improved thread safety checks. Marking objects as "lockable" has evolved into flagging some named "capability". clang reports the capability name when an error is reported (making this report a bit easier to understand). For example, a spinlock is now flagged as: typedef struct __rte_capability("spinlock") { volatile RTE_ATOMIC(int) locked; } rte_spinlock_t; For "exclusive" locking (spinlocks / write locks), the conversion is: - exclusive_lock_function -> acquire_capability - exclusive_trylock_function -> try_acquire_capability - unlock_function -> release_capability ... For "shared" locking (read locks): - shared_lock_function -> acquire_shared_capability - shared_trylock_function -> try_acquire_shared_capability - unlock_function -> release_shared_capability ... This RFC proposes to use those annotations (sticking to the convention of simply prefixing the compiler attributes with __rte_). The existing "old" annotations macros are left in place in case users started to rely on them. Note: DPDK requirements state that clang version must be >= 3.6 (following use of C11 standard). No check about availability of the new attributes has been added to this series, let's see what the CI thinks of this assumption... Comments welcome. -- David Marchand David Marchand (3): eal: add enhanced lock annotations eal: enhance lock annotations for spinlock and seqlock eal: enhance lock annotations for rwlock doc/api/doxy-api.conf.in | 12 ++ drivers/bus/dpaa/base/qbman/qman.c | 4 +- drivers/net/fm10k/fm10k_ethdev.c | 4 +- lib/eal/common/eal_memalloc.h | 2 +- lib/eal/common/eal_private.h | 2 +- lib/eal/include/generic/rte_rwlock.h | 23 ++-- lib/eal/include/generic/rte_spinlock.h | 14 +- lib/eal/include/rte_eal_memconfig.h | 28 ++-- lib/eal/include/rte_lock_annotations.h | 48 +++++++ lib/eal/include/rte_seqlock.h | 4 +- lib/ethdev/ethdev_driver.c | 4 +- lib/ethdev/ethdev_private.h | 4 +- lib/ethdev/rte_ethdev.c | 4 +- lib/graph/graph_private.h | 4 +- lib/hash/rte_cuckoo_hash.c | 8 +- lib/vhost/iotlb.h | 8 +- lib/vhost/vdpa.c | 2 +- lib/vhost/vhost.c | 10 +- lib/vhost/vhost.h | 24 ++-- lib/vhost/vhost_crypto.c | 14 +- lib/vhost/virtio_net.c | 170 ++++++++++++------------- lib/vhost/virtio_net_ctrl.c | 2 +- 22 files changed, 228 insertions(+), 167 deletions(-) -- 2.47.0