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 D711A43BE7; Mon, 26 Feb 2024 10:56:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF46C402BF; Mon, 26 Feb 2024 10:56:54 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 34BB940144 for ; Mon, 26 Feb 2024 10:56:53 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id 2B21543BE8; Mon, 26 Feb 2024 10:56:53 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/core Bug 1385] rt_bitops.h fails to give implied atomicity guarantees Date: Mon, 26 Feb 2024 09:56:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: core X-Bugzilla-Version: 23.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mattias.ronnblom@ericsson.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17089414130.60ae2.2504000 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 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 --17089414130.60ae2.2504000 Date: Mon, 26 Feb 2024 10:56:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1385 Bug ID: 1385 Summary: rt_bitops.h fails to give implied atomicity guarantees Product: DPDK Version: 23.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: mattias.ronnblom@ericsson.com Target Milestone: --- The documentation (and the naming) for the rte_bit_relaxed_*() functions in rte_bitops.h makes clear that all such functions have a relaxed memory orde= r. The use of the term "relaxed", which most C programmers likely are familiar with from the C11 memory model specification, itself implies that the operations are supposed to be atomic. Why otherwise mention the memory operations are relaxed? Relaxed is the default for non-atomic loads and sto= res. In addition, why otherwise declare the address as volatile? An even stronger indication are the test-and-set family of "relaxed" rte_bitops.h functions. "Test-and-set" in the low-level C programming conte= xt always implies an atomic operation. A non-atomic test-and-set does not make sense. In summary, a perfectly valid interpretation of the API contract is that the functions are atomic. However, their implementation is not, which may not be obvious to the causal API user. --=20 You are receiving this mail because: You are the assignee for the bug.= --17089414130.60ae2.2504000 Date: Mon, 26 Feb 2024 10:56:53 +0100 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1385
Summary rt_bitops.h fails to give implied atomicity guarantees
Product DPDK
Version 23.11
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component core
Assignee dev@dpdk.org
Reporter mattias.ronnblom@ericsson.com
Target Milestone --- 

The documentation (and the naming)=
 for the rte_bit_relaxed_*() functions in
rte_bitops.h makes clear that all such functions have a relaxed memory orde=
r.

The use of the term "relaxed", which most C programmers likely ar=
e familiar
with from the C11 memory model specification, itself implies that the
operations are supposed to be atomic. Why otherwise mention the memory
operations are relaxed? Relaxed is the default for non-atomic loads and sto=
res.
In addition, why otherwise declare the address as volatile?

An even stronger indication are the test-and-set family of "relaxed&qu=
ot;
rte_bitops.h functions. "Test-and-set" in the low-level C program=
ming context
always implies an atomic operation. A non-atomic test-and-set does not make
sense.

In summary, a perfectly valid interpretation of the API contract is that the
functions are atomic.

However, their implementation is not, which may not be obvious to the causal
API user.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17089414130.60ae2.2504000--