DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Robin Jarry" <rjarry@redhat.com>
Cc: "Thomas Monjalon" <thomas@monjalon.net>, <dev@dpdk.org>,
	"Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	<stable@dpdk.org>
Subject: Re: [PATCH v2 1/2] spinlock: remove volatile qualifier
Date: Mon, 18 May 2026 09:26:44 -0700	[thread overview]
Message-ID: <20260518092644.0c207992@phoenix.local> (raw)
In-Reply-To: <DILWG1XCA7NV.33OR3FAYCVVI0@redhat.com>

On Mon, 18 May 2026 17:14:54 +0200
"Robin Jarry" <rjarry@redhat.com> wrote:

> Hey Thomas,
> 
> Thomas Monjalon, May 18, 2026 at 17:07:
> > When compiling with C++20 standard requirement (default in GCC 16),
> > the increment and decrement of volatile variables are rejected:
> >
> > rte_spinlock.h:241:14: error:
> > 	'++' expression of 'volatile'-qualified type is deprecated
> > rte_spinlock.h:252:21: error:
> > 	'--' expression of 'volatile'-qualified type is deprecated
> > rte_spinlock.h:278:14: error:
> > 	'++' expression of 'volatile'-qualified type is deprecated
> >
> > The count field of rte_spinlock_recursive_t
> > does not need the volatile qualifier
> > because it is only accessed by the thread holding the lock,
> > which already provides the necessary memory ordering.
> >
> > The user field can be accessed outside of the lock,
> > so it must handled as a C11 atomic variable.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > v1: drop volatile keyword
> > v2: make user an atomic variable
> > ---
> >  lib/eal/include/generic/rte_spinlock.h | 17 ++++++++---------
> >  1 file changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/lib/eal/include/generic/rte_spinlock.h b/lib/eal/include/generic/rte_spinlock.h
> > index c907d4e45c..5d810b682a 100644
> > --- a/lib/eal/include/generic/rte_spinlock.h
> > +++ b/lib/eal/include/generic/rte_spinlock.h
> > @@ -197,8 +197,8 @@ rte_spinlock_trylock_tm(rte_spinlock_t *sl)
> >   */
> >  typedef struct {
> >  	rte_spinlock_t sl; /**< the actual spinlock */
> > -	volatile int user; /**< core id using lock, -1 for unused */
> > -	volatile int count; /**< count of time this lock has been called */
> > +	RTE_ATOMIC(int) user; /**< core id using lock, -1 for unused */
> > +	int count; /**< count of time this lock has been called */
> >  } rte_spinlock_recursive_t;
> >  
> >  /**
> > @@ -215,7 +215,7 @@ typedef struct {
> >  static inline void rte_spinlock_recursive_init(rte_spinlock_recursive_t *slr)
> >  {
> >  	rte_spinlock_init(&slr->sl);
> > -	slr->user = -1;
> > +	rte_atomic_store_explicit(&slr->user, -1, rte_memory_order_relaxed);
> >  	slr->count = 0;
> >  }
> >  
> > @@ -230,9 +230,9 @@ static inline void rte_spinlock_recursive_lock(rte_spinlock_recursive_t *slr)
> >  {
> >  	int id = rte_gettid();
> >  
> > -	if (slr->user != id) {
> > +	if (rte_atomic_load_explicit(&slr->user, rte_memory_order_relaxed) != id) {  
> 
> This needs to be rte_memory_order_acquire

No it does not. There is no dependency here.
The acquire is inside the spinlock.

> 
> >  		rte_spinlock_lock(&slr->sl);
> > -		slr->user = id;
> > +		rte_atomic_store_explicit(&slr->user, id, rte_memory_order_relaxed);  
> 
> And rte_memory_order_release

Ditto.

> 
> >  	}
> >  	slr->count++;
> >  }
> > @@ -246,10 +246,9 @@ static inline void rte_spinlock_recursive_unlock(rte_spinlock_recursive_t *slr)
> >  	__rte_no_thread_safety_analysis
> >  {
> >  	if (--(slr->count) == 0) {  
> 
> This code is completely broken. Any thread can unlock without any check.

I would make an RTE_ASSERT() that id matched current thread id.
Since caller holds lock, no atomic required for that.

  parent reply	other threads:[~2026-05-18 16:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04  8:37 [PATCH] spinlock: remove volatile qualifier Thomas Monjalon
2026-05-04  9:06 ` Thomas Monjalon
2026-05-04  9:12   ` [PATCH] spinlock: fix API comments Thomas Monjalon
2026-05-04 12:46     ` Thomas Monjalon
2026-05-18 13:57   ` [PATCH] spinlock: remove volatile qualifier Thomas Monjalon
2026-05-04 17:02 ` Stephen Hemminger
2026-05-05  7:01   ` Thomas Monjalon
2026-05-05 13:24     ` Stephen Hemminger
2026-05-18 15:07 ` [PATCH v2 1/2] " Thomas Monjalon
2026-05-18 15:07   ` [PATCH v2 2/2] spinlock: fix API comments Thomas Monjalon
2026-05-18 15:14   ` [PATCH v2 1/2] spinlock: remove volatile qualifier Robin Jarry
2026-05-18 15:25     ` Thomas Monjalon
2026-05-18 15:28       ` Bruce Richardson
2026-05-19  9:17         ` Robin Jarry
2026-05-19 10:35           ` Thomas Monjalon
2026-05-18 16:26     ` Stephen Hemminger [this message]
2026-05-18 16:28   ` Stephen Hemminger
2026-05-19 10:34 ` [PATCH v3 1/3] " Thomas Monjalon
2026-05-19 10:34   ` [PATCH v3 2/3] spinlock: add debug checks in recursive unlock Thomas Monjalon
2026-05-19 11:19     ` Thomas Monjalon
2026-05-19 11:47     ` Robin Jarry
2026-05-19 10:34   ` [PATCH v3 3/3] spinlock: fix API comments Thomas Monjalon
2026-05-19 11:03   ` [PATCH v3 1/3] spinlock: remove volatile qualifier Bruce Richardson
2026-05-19 13:32   ` Stephen Hemminger
2026-05-19 15:02   ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260518092644.0c207992@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@huawei.com \
    --cc=rjarry@redhat.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox