From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <bug-1385-3@http.bugs.dpdk.org/>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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

<html>
    <head>
      <base href=3D"https://bugs.dpdk.org/">
    </head>
    <body><table border=3D"1" cellspacing=3D"0" cellpadding=3D"8" class=3D"=
bz_new_table">
        <tr>
          <th>Bug ID</th>
          <td><a class=3D"bz_bug_link=20
          bz_status_UNCONFIRMED "
   title=3D"UNCONFIRMED - rt_bitops.h fails to give implied atomicity guara=
ntees"
   href=3D"https://bugs.dpdk.org/show_bug.cgi?id=3D1385">1385</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>rt_bitops.h fails to give implied atomicity guarantees
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>DPDK
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>23.11
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>UNCONFIRMED
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>Normal
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>core
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>dev&#64;dpdk.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>mattias.ronnblom&#64;ericsson.com
          </td>
        </tr>

        <tr>
          <th>Target Milestone</th>
          <td>---
          </td>
        </tr></table>
      <p>
        <div class=3D"bz_comment_block">
          <pre class=3D"bz_comment_text">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 &quot;relaxed&quot;, 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 &quot;relaxed&qu=
ot;
rte_bitops.h functions. &quot;Test-and-set&quot; 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.
          </pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
      <div itemscope itemtype=3D"http://schema.org/EmailMessage">
        <div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/Vi=
ewAction">
=20=20=20=20=20=20=20=20=20=20
          <link itemprop=3D"url" href=3D"https://bugs.dpdk.org/show_bug.cgi=
?id=3D1385">
          <meta itemprop=3D"name" content=3D"View bug">
        </div>
        <meta itemprop=3D"description" content=3D"Bugzilla bug update notif=
ication">
      </div>
    </body>
</html>=

--17089414130.60ae2.2504000--