Re: [PATCH v2 0/3] Improve lock annotations

[David Marchand <david.marchand@redhat.com>]

On Thu, Dec 12, 2024 at 5:02 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> 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 series 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).
>
> Comments welcome.

Just a note on Intel CI report.
http://mails.dpdk.org/archives/test-report/2024-December/834120.html

(As reported a few times), this CI reports an error on documentation generation.
I can't be sure but this failure here is most likely due to this CI
filtering out of the patches any update on doc/.


-- 
David Marchand