[PATCH 2/3] docs: atomic_ops: Move two paragraphs into the warning block above

["Jonathan Neuschäfer" <j.neuschaefer@gmx.net>]

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@gmx.net>
---
 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