2020-03-08 19:58:45

by J. Neuschäfer

[permalink] [raw]
Subject: [PATCH 0/3] docs: a few improvements for atomic_ops.rst

Hi,

this is a short series of unrelated fixes that make the atomic
operations documentation look and read a bit better.

Jonathan Neuschäfer (3):
docs: atomic_ops: Remove colons where they don't make sense
docs: atomic_ops: Move two paragraphs into the warning block above
docs: atomic_ops: Steer readers towards using refcount_t for reference
counts

Documentation/core-api/atomic_ops.rst | 24 ++++++++++++-------
Documentation/core-api/refcount-vs-atomic.rst | 2 ++
2 files changed, 17 insertions(+), 9 deletions(-)

--
2.20.1


2020-03-08 20:00:59

by J. Neuschäfer

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

Signed-off-by: Jonathan Neuschäfer <[email protected]>
---
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

2020-03-08 21:08:32

by Randy Dunlap

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

On 3/8/20 1:00 PM, Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer <[email protected]>
> ---
> 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

2020-03-08 21:26:50

by J. Neuschäfer

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

On Sun, Mar 08, 2020 at 02:07:46PM -0700, Randy Dunlap wrote:
> On 3/8/20 1:00 PM, Jonathan Neuschäfer wrote:
[...]
> > + More recently, reference counts are implement using the
>
> implemented

Indeed, good catch.

Thanks,
Jonathan Neuschäfer


Attachments:
(No filename) (312.00 B)
signature.asc (849.00 B)
Download all attachments

2020-03-09 09:07:53

by Peter Zijlstra

[permalink] [raw]
Subject: Re: [PATCH 0/3] docs: a few improvements for atomic_ops.rst

On Sun, Mar 08, 2020 at 08:56:15PM +0100, Jonathan Neusch?fer wrote:
> Hi,
>
> this is a short series of unrelated fixes that make the atomic
> operations documentation look and read a bit better.
>
> Jonathan Neusch?fer (3):
> docs: atomic_ops: Remove colons where they don't make sense
> docs: atomic_ops: Move two paragraphs into the warning block above
> docs: atomic_ops: Steer readers towards using refcount_t for reference
> counts
>
> Documentation/core-api/atomic_ops.rst | 24 ++++++++++++-------

FWIW, I consider this a dead document. I've written
Documentation/atomic_t.txt and Documentation/atomic_bitops.txt as a
replacement. If there is anything in atomic_ops you feel is missing from
those two, please tell as I'm planing to delete atomic_ops soon.

2020-03-16 15:49:13

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH 0/3] docs: a few improvements for atomic_ops.rst

On Mon, Mar 09, 2020 at 10:06:50AM +0100, Peter Zijlstra wrote:
> On Sun, Mar 08, 2020 at 08:56:15PM +0100, Jonathan Neusch?fer wrote:
> > Hi,
> >
> > this is a short series of unrelated fixes that make the atomic
> > operations documentation look and read a bit better.
> >
> > Jonathan Neusch?fer (3):
> > docs: atomic_ops: Remove colons where they don't make sense
> > docs: atomic_ops: Move two paragraphs into the warning block above
> > docs: atomic_ops: Steer readers towards using refcount_t for reference
> > counts
> >
> > Documentation/core-api/atomic_ops.rst | 24 ++++++++++++-------
>
> FWIW, I consider this a dead document. I've written
> Documentation/atomic_t.txt and Documentation/atomic_bitops.txt as a
> replacement. If there is anything in atomic_ops you feel is missing from
> those two, please tell as I'm planing to delete atomic_ops soon.

For the deletion:

Acked-by: Will Deacon <[email protected]>

Will