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
