From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755381AbcHSBwL (ORCPT ); Thu, 18 Aug 2016 21:52:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45430 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755313AbcHSBwH (ORCPT ); Thu, 18 Aug 2016 21:52:07 -0400 Date: Thu, 18 Aug 2016 14:06:10 -0400 From: Jessica Yu To: Petr Mladek Cc: Josh Poimboeuf , Miroslav Benes , Jiri Kosina , Chris J Arges , Eugene Shatokhin , live-patching@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Documentation: livepatch: add section about arch-specific code Message-ID: <20160818180610.GB8272@packer-debian-8-amd64.digitalocean.com> References: <1471481911-5003-1-git-send-email-jeyu@redhat.com> <1471481911-5003-4-git-send-email-jeyu@redhat.com> <20160818095725.GD26194@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160818095725.GD26194@pathway.suse.cz> X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 18 Aug 2016 18:06:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Petr Mladek [18/08/16 11:57 +0200]: >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 >> --- >> 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". Agreed, poor word choice there. Let's just swap "can" with "must." Jessica