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

[Randy Dunlap <rdunlap@infradead.org>]

On 3/8/20 1:00 PM, Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
>  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

                                               implemented

> +        :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.


-- 
~Randy