[PATCH 3/3] docs: atomic_ops: Steer readers towards using refcount_t for reference counts

[Jonathan NeuschÃfer]

Signed-off-by: Jonathan NeuschÃfer <j.neuschaefer@xxxxxxx>
---
 Documentation/core-api/atomic_ops.rst         | 6 ++++++
 Documentation/core-api/refcount-vs-atomic.rst | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/core-api/atomic_ops.rst b/Documentation/core-api/atomic_ops.rst
index 73033fc954ad..37a0ffe1a9f1 100644
--- a/Documentation/core-api/atomic_ops.rst
+++ b/Documentation/core-api/atomic_ops.rst
@@ -392,6 +392,12 @@ be guaranteed that no other entity can be accessing the object::
 	memory barriers in kfree_skb() that exposed the atomic_t memory barrier
 	requirements quite clearly.

+.. note::
+
+        More recently, reference counts are implement using the
+        :ref:`refcount_t <refcount_t_vs_atomic_t>` type, which works like
+        atomic_t but protects against wraparound.
+
 Given the above scheme, it must be the case that the obj->active
 update done by the obj list deletion be visible to other processors
 before the atomic counter decrement is performed.
diff --git a/Documentation/core-api/refcount-vs-atomic.rst b/Documentation/core-api/refcount-vs-atomic.rst
index 79a009ce11df..d979ff5166ae 100644
--- a/Documentation/core-api/refcount-vs-atomic.rst
+++ b/Documentation/core-api/refcount-vs-atomic.rst
@@ -1,3 +1,5 @@
+.. _refcount_t_vs_atomic_t:
+
 ===================================
 refcount_t API compared to atomic_t
 ===================================
--
2.20.1