[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116105236.1916-1-hdanton@sina.com>
Date: Thu, 16 Jan 2025 18:52:35 +0800
From: Hillf Danton <hdanton@...a.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
akpm@...ux-foundation.org,
willy@...radead.org,
hannes@...xchg.org,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
kernel-team@...roid.com
Subject: Re: [PATCH v9 10/17] refcount: introduce __refcount_{add|inc}_not_zero_limited
On Wed, 15 Jan 2025 10:39:55 +0100 Peter Zijlstra <peterz@...radead.org>
>
> Sigh; don't let hillf confuse you. *IF* you need an acquire it will be
> in the part where you wait for readers to go away. But even there, think
> about what you're serializing against. Readers don't typically modify
> things.
>
> And modifications are fully serialized by mmap_sem^H^H^Hlock.
>
^H^H^H
- * Do note that inc_not_zero() provides a control dependency which will order
- * future stores against the inc, this ensures we'll never modify the object
- * if we did not in fact acquire a reference.
+ * Do note that inc_not_zero() does provide acquire order, which will order
+ * future load and stores against the inc, this ensures all subsequent accesses
+ * are from this object and not anything previously occupying this memory --
+ * consider SLAB_TYPESAFE_BY_RCU.
*
* The decrements will provide release order, such that all the prior loads and
* stores will be issued before, it also provides a control dependency, which
@@ -144,7 +145,7 @@ bool __refcount_add_not_zero(int i, refcount_t *r, int *oldp)
do {
if (!old)
break;
- } while (!atomic_try_cmpxchg_relaxed(&r->refs, &old, old + i));
+ } while (!atomic_try_cmpxchg_acquire(&r->refs, &old, old + i));
Powered by blists - more mailing lists