docs/livepatch: Unify style of livepatch documentation in the ReST format

Make the structure of "Livepatch module Elf format" document similar
to the main "Livepatch" document.

Also make the structure of "(Un)patching Callbacks" document similar
to the "Shadow Variables" document.

It fixes the most visible inconsistencies of the documentation
generated from the ReST format.
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Documentation/livepatch/callbacks.rst

@@ -4,7 +4,7 @@
 
 Livepatch (un)patch-callbacks provide a mechanism for livepatch modules
 to execute callback functions when a kernel object is (un)patched.  They
-can be considered a "power feature" that extends livepatching abilities
+can be considered a **power feature** that **extends livepatching abilities**
 to include:
 
   - Safe updates to global data
@@ -17,6 +17,9 @@ In most cases, (un)patch callbacks will need to be used in conjunction
 with memory barriers and kernel synchronization primitives, like
 mutexes/spinlocks, or even stop_machine(), to avoid concurrency issues.
 
+1. Motivation
+=============
+
 Callbacks differ from existing kernel facilities:
 
   - Module init/exit code doesn't run when disabling and re-enabling a
@@ -28,6 +31,9 @@ Callbacks are part of the klp_object structure and their implementation
 is specific to that klp_object.  Other livepatch objects may or may not
 be patched, irrespective of the target klp_object's current state.
 
+2. Callback types
+=================
+
 Callbacks can be registered for the following livepatch actions:
 
   * Pre-patch
@@ -47,6 +53,9 @@ Callbacks can be registered for the following livepatch actions:
                    been restored and no tasks are running patched code,
                    used to cleanup pre-patch callback resources
 
+3. How it works
+===============
+
 Each callback is optional, omitting one does not preclude specifying any
 other.  However, the livepatching core executes the handlers in
 symmetry: pre-patch callbacks have a post-unpatch counterpart and
@@ -90,11 +99,14 @@ If the object did successfully patch, but the patch transition never
 started for some reason (e.g., if another object failed to patch),
 only the post-unpatch callback will be called.
 
+4. Use cases
+============
 
-Example Use-cases
-=================
+Sample livepatch modules demonstrating the callback API can be found in
+samples/livepatch/ directory.  These samples were modified for use in
+kselftests and can be found in the lib/livepatch directory.
 
-Update global data
+Global data update
 ------------------
 
 A pre-patch callback can be useful to update a global variable.  For
@@ -107,24 +119,15 @@ patch the data *after* patching is complete with a post-patch callback,
 so that tcp_send_challenge_ack() could first be changed to read
 sysctl_tcp_challenge_ack_limit with READ_ONCE.
 
-
-Support __init and probe function patches
+__init and probe function patches support
 -----------------------------------------
 
 Although __init and probe functions are not directly livepatch-able, it
 may be possible to implement similar updates via pre/post-patch
 callbacks.
 
-48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST") change the way that
+The commit ``48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST")`` change the way that
 virtnet_probe() initialized its driver's net_device features.  A
 pre/post-patch callback could iterate over all such devices, making a
 similar change to their hw_features value.  (Client functions of the
 value may need to be updated accordingly.)
-
-
-Other Examples
-==============
-
-Sample livepatch modules demonstrating the callback API can be found in
-samples/livepatch/ directory.  These samples were modified for use in
-kselftests and can be found in the lib/livepatch directory.

Documentation/livepatch/module-elf-format.rst

@@ -7,30 +7,18 @@ This document outlines the Elf format requirements that livepatch modules must f
 
 .. Table of Contents
 
-   0. Background and motivation
-   1. Livepatch modinfo field
-   2. Livepatch relocation sections
-      2.1 What are livepatch relocation sections?
-      2.2 Livepatch relocation section format
-          2.2.1 Required flags
-          2.2.2 Required name format
-          2.2.3 Example livepatch relocation section names
-          2.2.4 Example `readelf --sections` output
-          2.2.5 Example `readelf --relocs` output
-   3. Livepatch symbols
-      3.1 What are livepatch symbols?
-      3.2 A livepatch module's symbol table
-      3.3 Livepatch symbol format
-          3.3.1 Required flags
-          3.3.2 Required name format
-          3.3.3 Example livepatch symbol names
-          3.3.4 Example `readelf --symbols` output
-   4. Architecture-specific sections
-   5. Symbol table and Elf section access
-
-----------------------------
-0. Background and motivation
-----------------------------
+   1. Background and motivation
+   2. Livepatch modinfo field
+   3. Livepatch relocation sections
+      3.1 Livepatch relocation section format
+   4. Livepatch symbols
+      4.1 A livepatch module's symbol table
+      4.2 Livepatch symbol format
+   5. Architecture-specific sections
+   6. Symbol table and Elf section access
+
+1. Background and motivation
+============================
 
 Formerly, livepatch required separate architecture-specific code to write
 relocations. However, arch-specific code to write relocations already
@@ -52,8 +40,8 @@ relocation sections and symbols, which are described in this document. The
 Elf constants used to mark livepatch symbols and relocation sections were
 selected from OS-specific ranges according to the definitions from glibc.
 
-0.1 Why does livepatch need to write its own relocations?
----------------------------------------------------------
+Why does livepatch need to write its own relocations?
+-----------------------------------------------------
 A typical livepatch module contains patched versions of functions that can
 reference non-exported global symbols and non-included local symbols.
 Relocations referencing these types of symbols cannot be left in as-is
@@ -72,13 +60,8 @@ relas reference are special livepatch symbols (see section 2 and 3). The
 arch-specific livepatch relocation code is replaced by a call to
 apply_relocate_add().
 
-================================
-PATCH MODULE FORMAT REQUIREMENTS
-================================
-
---------------------------
-1. Livepatch modinfo field
---------------------------
+2. Livepatch modinfo field
+==========================
 
 Livepatch modules are required to have the "livepatch" modinfo attribute.
 See the sample livepatch module in samples/livepatch/ for how this is done.
@@ -87,8 +70,10 @@ Livepatch modules can be identified by users by using the 'modinfo' command
 and looking for the presence of the "livepatch" field. This field is also
 used by the kernel module loader to identify livepatch modules.
 
-Example modinfo output:
------------------------
+Example:
+--------
+
+**Modinfo output:**
 
 ::
 
@@ -99,13 +84,9 @@ Example modinfo output:
 	depends:
 	vermagic:		4.3.0+ SMP mod_unload
 
---------------------------------
-2. Livepatch relocation sections
---------------------------------
+3. Livepatch relocation sections
+================================
 
--------------------------------------------
-2.1 What are livepatch relocation sections?
--------------------------------------------
 A livepatch module manages its own Elf relocation sections to apply
 relocations to modules as well as to the kernel (vmlinux) at the
 appropriate time. For example, if a patch module patches a driver that is
@@ -130,12 +111,9 @@ Every symbol referenced by a rela in a livepatch relocation section is a
 livepatch symbol. These must be resolved before livepatch can call
 apply_relocate_add(). See Section 3 for more information.
 
----------------------------------------
-2.2 Livepatch relocation section format
----------------------------------------
+3.1 Livepatch relocation section format
+=======================================
 
-2.2.1 Required flags
---------------------
 Livepatch relocation sections must be marked with the SHF_RELA_LIVEPATCH
 section flag. See include/uapi/linux/elf.h for the definition. The module
 loader recognizes this flag and will avoid applying those relocation sections
@@ -143,8 +121,6 @@ at patch module load time. These sections must also be marked with SHF_ALLOC,
 so that the module loader doesn't discard them on module load (i.e. they will
 be copied into memory along with the other SHF_ALLOC sections).
 
-2.2.2 Required name format
---------------------------
 The name of a livepatch relocation section must conform to the following
 format::
 
@@ -153,19 +129,28 @@ format::
   |________||_____| |__________|
      [A]      [B]        [C]
 
-  [A] The relocation section name is prefixed with the string ".klp.rela."
-  [B] The name of the object (i.e. "vmlinux" or name of module) to
+[A]
+  The relocation section name is prefixed with the string ".klp.rela."
+
+[B]
+  The name of the object (i.e. "vmlinux" or name of module) to
   which the relocation section belongs follows immediately after the prefix.
-  [C] The actual name of the section to which this relocation section applies.
 
-2.2.3 Example livepatch relocation section names:
--------------------------------------------------
-.klp.rela.ext4.text.ext4_attr_store
-.klp.rela.vmlinux.text.cmdline_proc_show
+[C]
+  The actual name of the section to which this relocation section applies.
+
+Examples:
+---------
 
-2.2.4 Example `readelf --sections` output for a patch
-module that patches vmlinux and modules 9p, btrfs, ext4:
---------------------------------------------------------
+**Livepatch relocation section names:**
+
+::
+
+  .klp.rela.ext4.text.ext4_attr_store
+  .klp.rela.vmlinux.text.cmdline_proc_show
+
+**`readelf --sections` output for a patch
+module that patches vmlinux and modules 9p, btrfs, ext4:**
 
 ::
 
@@ -182,13 +167,14 @@ module that patches vmlinux and modules 9p, btrfs, ext4:
   [ snip ]                                       ^                                             ^
                                                  |                                             |
                                                 [*]                                           [*]
-  [*] Livepatch relocation sections are SHT_RELA sections but with a few special
+
+[*]
+  Livepatch relocation sections are SHT_RELA sections but with a few special
   characteristics. Notice that they are marked SHF_ALLOC ("A") so that they will
   not be discarded when the module is loaded into memory, as well as with the
   SHF_RELA_LIVEPATCH flag ("o" - for OS-specific).
 
-2.2.5 Example `readelf --relocs` output for a patch module:
------------------------------------------------------------
+**`readelf --relocs` output for a patch module:**
 
 ::
 
@@ -201,15 +187,13 @@ module that patches vmlinux and modules 9p, btrfs, ext4:
   [ snip ]                                                                   ^
                                                                              |
                                                                             [*]
-  [*] Every symbol referenced by a relocation is a livepatch symbol.
 
---------------------
-3. Livepatch symbols
---------------------
+[*]
+  Every symbol referenced by a relocation is a livepatch symbol.
+
+4. Livepatch symbols
+====================
 
--------------------------------
-3.1 What are livepatch symbols?
--------------------------------
 Livepatch symbols are symbols referred to by livepatch relocation sections.
 These are symbols accessed from new versions of functions for patched
 objects, whose addresses cannot be resolved by the module loader (because
@@ -229,9 +213,8 @@ loader can identify and ignore them. Livepatch modules keep these symbols
 in their symbol tables, and the symbol table is made accessible through
 module->symtab.
 
--------------------------------------
-3.2 A livepatch module's symbol table
--------------------------------------
+4.1 A livepatch module's symbol table
+=====================================
 Normally, a stripped down copy of a module's symbol table (containing only
 "core" symbols) is made available through module->symtab (See layout_symtab()
 in kernel/module.c). For livepatch modules, the symbol table copied into memory
@@ -255,18 +238,13 @@ For example, take this particular rela from a livepatch module:::
   94: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0
   [ snip ]
 
----------------------------
-3.3 Livepatch symbol format
----------------------------
+4.2 Livepatch symbol format
+===========================
 
-3.3.1 Required flags
---------------------
 Livepatch symbols must have their section index marked as SHN_LIVEPATCH, so
 that the module loader can identify them and not attempt to resolve them.
 See include/uapi/linux/elf.h for the actual definitions.
 
-3.3.2 Required name format
---------------------------
 Livepatch symbol names must conform to the following format::
 
   .klp.sym.objname.symbol_name,sympos
@@ -274,17 +252,26 @@ Livepatch symbol names must conform to the following format::
   |_______||_____| |_________| |
      [A]     [B]       [C]    [D]
 
-  [A] The symbol name is prefixed with the string ".klp.sym."
-  [B] The name of the object (i.e. "vmlinux" or name of module) to
+[A]
+  The symbol name is prefixed with the string ".klp.sym."
+
+[B]
+  The name of the object (i.e. "vmlinux" or name of module) to
   which the symbol belongs follows immediately after the prefix.
-  [C] The actual name of the symbol.
-  [D] The position of the symbol in the object (as according to kallsyms)
+
+[C]
+  The actual name of the symbol.
+
+[D]
+  The position of the symbol in the object (as according to kallsyms)
   This is used to differentiate duplicate symbols within the same
   object. The symbol position is expressed numerically (0, 1, 2...).
   The symbol position of a unique symbol is 0.
 
-3.3.3 Example livepatch symbol names:
--------------------------------------
+Examples:
+---------
+
+**Livepatch symbol names:**
 
 ::
 
@@ -292,8 +279,7 @@ Livepatch symbol names must conform to the following format::
 	.klp.sym.vmlinux.printk,0
 	.klp.sym.btrfs.btrfs_ktype,0
 
-3.3.4 Example `readelf --symbols` output for a patch module:
-------------------------------------------------------------
+**`readelf --symbols` output for a patch module:**
 
 ::
 
@@ -307,12 +293,13 @@ Livepatch symbol names must conform to the following format::
     [ snip ]                                               ^
                                                            |
                                                           [*]
-  [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
+
+[*]
+  Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
   "OS" means OS-specific.
 
----------------------------------
-4. Architecture-specific sections
----------------------------------
+5. Architecture-specific sections
+=================================
 Architectures may override arch_klp_init_object_loaded() to perform
 additional arch-specific tasks when a target module loads, such as applying
 arch-specific sections. On x86 for example, we must apply per-object
@@ -321,9 +308,8 @@ These sections must be prefixed with ".klp.arch.$objname." so that they can
 be easily identified when iterating through a patch module's Elf sections
 (See arch/x86/kernel/livepatch.c for a complete example).
 
---------------------------------------
-5. Symbol table and Elf section access
---------------------------------------
+6. Symbol table and Elf section access
+======================================
 A livepatch module's symbol table is accessible through module->symtab.
 
 Since apply_relocate_add() requires access to a module's section headers,