locking.rst: Update some ReST markups

Correct a few minor issues with ReST notation used on
this file (produced by an automatic tool).

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This commit is contained in:
Mauro Carvalho Chehab 2017-05-11 16:15:16 -03:00
parent 475c5ef83d
commit dc89fca93e

View File

@ -93,13 +93,13 @@ Locking in the Linux Kernel
=========================== ===========================
If I could give you one piece of advice: never sleep with anyone crazier If I could give you one piece of advice: never sleep with anyone crazier
than yourself. But if I had to give you advice on locking: *keep it than yourself. But if I had to give you advice on locking: **keep it
simple*. simple**.
Be reluctant to introduce new locks. Be reluctant to introduce new locks.
Strangely enough, this last one is the exact reverse of my advice when Strangely enough, this last one is the exact reverse of my advice when
you *have* slept with someone crazier than yourself. And you should you **have** slept with someone crazier than yourself. And you should
think about getting a big dog. think about getting a big dog.
Two Main Types of Kernel Locks: Spinlocks and Mutexes Two Main Types of Kernel Locks: Spinlocks and Mutexes
@ -311,7 +311,7 @@ Pete Zaitcev gives the following summary:
Table of Minimum Requirements Table of Minimum Requirements
----------------------------- -----------------------------
The following table lists the *minimum* locking requirements between The following table lists the **minimum** locking requirements between
various contexts. In some cases, the same context can only be running on various contexts. In some cases, the same context can only be running on
one CPU at a time, so no locking is required for that context (eg. a one CPU at a time, so no locking is required for that context (eg. a
particular thread can only run on one CPU at a time, but if it needs particular thread can only run on one CPU at a time, but if it needs
@ -703,7 +703,7 @@ reference count, but they are more complicated.
Using Atomic Operations For The Reference Count Using Atomic Operations For The Reference Count
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In practice, ``atomic_t`` would usually be used for refcnt. There are a In practice, :c:type:`atomic_t` would usually be used for refcnt. There are a
number of atomic operations defined in ``include/asm/atomic.h``: these number of atomic operations defined in ``include/asm/atomic.h``: these
are guaranteed to be seen atomically from all CPUs in the system, so no are guaranteed to be seen atomically from all CPUs in the system, so no
lock is required. In this case, it is simpler than using spinlocks, lock is required. In this case, it is simpler than using spinlocks,
@ -1321,7 +1321,7 @@ from user context, and can sleep.
- :c:func:`put_user()` - :c:func:`put_user()`
- ``kmalloc(GFP_KERNEL)`` - :c:func:`kmalloc(GFP_KERNEL) <kmalloc>`
- :c:func:`mutex_lock_interruptible()` and - :c:func:`mutex_lock_interruptible()` and
:c:func:`mutex_lock()` :c:func:`mutex_lock()`
@ -1431,10 +1431,10 @@ tasklet
timer timer
A dynamically-registrable software interrupt, which is run at (or close A dynamically-registrable software interrupt, which is run at (or close
to) a given time. When running, it is just like a tasklet (in fact, they to) a given time. When running, it is just like a tasklet (in fact, they
are called from the TIMER_SOFTIRQ). are called from the ``TIMER_SOFTIRQ``).
UP UP
Uni-Processor: Non-SMP. (CONFIG_SMP=n). Uni-Processor: Non-SMP. (``CONFIG_SMP=n``).
User Context User Context
The kernel executing on behalf of a particular process (ie. a system The kernel executing on behalf of a particular process (ie. a system