On Wed 2016-08-17 20:58:30, Jessica Yu wrote:
> Document usage of arch-specific elf sections in livepatch as well
> as implementation of arch-specific code.
>
> Signed-off-by: Jessica Yu <jeyu@xxxxxxxxxx>
> ---
> Documentation/livepatch/module-elf-format.txt | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt
> index eedbdcf..02bfafa 100644
> --- a/Documentation/livepatch/module-elf-format.txt
> +++ b/Documentation/livepatch/module-elf-format.txt
> @@ -25,7 +25,8 @@ Table of Contents
> 3.3.2 Required name format
> 3.3.3 Example livepatch symbol names
> 3.3.4 Example `readelf --symbols` output
> -4. Symbol table and Elf section access
> +4. Architecture-specific sections
> +5. Symbol table and Elf section access
>
> ----------------------------
> 0. Background and motivation
> @@ -46,7 +47,7 @@ architecture.
>
> Since apply_relocate_add() requires access to a module's section header
> table, symbol table, and relocation section indices, Elf information is
> -preserved for livepatch modules (see section 4). Livepatch manages its own
> +preserved for livepatch modules (see section 5). Livepatch manages its own
> 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.
> @@ -117,7 +118,7 @@ also possible for a livepatch module to have no livepatch relocation
> sections, as in the case of the sample livepatch module (see
> samples/livepatch).
>
> -Since Elf information is preserved for livepatch modules (see Section 4), a
> +Since Elf information is preserved for livepatch modules (see Section 5), a
> livepatch relocation section can be applied simply by passing in the
> appropriate section index to apply_relocate_add(), which then uses it to
> access the relocation section and apply the relocations.
> @@ -292,8 +293,19 @@ Symbol table '.symtab' contains 127 entries:
> [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
> "OS" means OS-specific.
>
> +---------------------------------
> +4. 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
> +.altinstructions and .parainstructions sections when a target module loads.
> +These sections can be prefixed with ".klp.arch.$objname." so that they can
^^^
I would personally use "must" instead of "can". Or replace "can be prefixed"
with "are prefixed".
Otherwise, it looks fine.
Reviewed-by: Petr Mladek <pmladek@xxxxxxxx>
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
