These two paragraphs seem to be semantically part of the warning text,
so let's adjust the formatting accordingly.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
---
Documentation/core-api/atomic_ops.rst | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/core-api/atomic_ops.rst b/Documentation/core-api/atomic_ops.rst
index 650b9693469a..73033fc954ad 100644
--- a/Documentation/core-api/atomic_ops.rst
+++ b/Documentation/core-api/atomic_ops.rst
@@ -473,14 +473,14 @@ operation.
above to return "long" and just returning something like "old_val &
mask" because that will not work.
-For one thing, this return value gets truncated to int in many code
-paths using these interfaces, so on 64-bit if the bit is set in the
-upper 32-bits then testers will never see that.
-
-One great example of where this problem crops up are the thread_info
-flag operations. Routines such as test_and_set_ti_thread_flag() chop
-the return value into an int. There are other places where things
-like this occur as well.
+ For one thing, this return value gets truncated to int in many code
+ paths using these interfaces, so on 64-bit if the bit is set in the
+ upper 32-bits then testers will never see that.
+
+ One great example of where this problem crops up are the thread_info
+ flag operations. Routines such as test_and_set_ti_thread_flag() chop
+ the return value into an int. There are other places where things
+ like this occur as well.
These routines, like the atomic_t counter operations returning values,
must provide explicit memory barrier semantics around their execution.
--
2.20.1
