All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@redhat.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
	Jonathan Corbet <corbet@lwn.net>, Miroslav Benes <mbenes@suse.cz>,
	linux-api@vger.kernel.org, live-patching@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: module: preserve Elf information for livepatch modules
Date: Mon, 8 Feb 2016 15:34:42 -0500	[thread overview]
Message-ID: <20160208203441.GB27290@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <20160208201039.GC23106@treble.redhat.com>

+++ Josh Poimboeuf [08/02/16 14:10 -0600]:
>On Wed, Feb 03, 2016 at 08:11:07PM -0500, Jessica Yu wrote:
>> For livepatch modules, copy Elf section, symbol, and string information
>> from the load_info struct in the module loader. Persist copies of the
>> original symbol table and string table.
>>
>> Livepatch manages its own relocation sections in order to reuse module
>> loader code to write relocations. Livepatch modules must preserve Elf
>> information such as section indices in order to apply livepatch relocation
>> sections using the module loader's apply_relocate_add() function.
>>
>> In order to apply livepatch relocation sections, livepatch modules must
>> keep a complete copy of their original symbol table in memory. Normally, a
>> stripped down copy of a module's symbol table (containing only "core"
>> symbols) is made available through module->core_symtab. But for livepatch
>> modules, the symbol table copied into memory on module load must be exactly
>> the same as the symbol table produced when the patch module was compiled.
>> This is because the relocations in each livepatch relocation section refer
>> to their respective symbols with their symbol indices, and the original
>> symbol indices (and thus the symtab ordering) must be preserved in order
>> for apply_relocate_add() to find the right symbol.
>
>This patch didn't apply clean to linux-next/master.  I didn't
>investigate why, but maybe it depends on the other patch set which
>removes the notifiers?  (If so, that should be mentioned in the cover
>letter.)

A very recent commit (8244062ef) introduced some changes
kernel/module.c that intersect with this patch, so I think this is why
the patch didn't apply cleanly to today's tree...Anyhow I will rebase
again before sending out v5. Thanks for the comments :-)

Jessica

WARNING: multiple messages have this Message-ID (diff)
From: Jessica Yu <jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Josh Poimboeuf <jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>,
	Seth Jennings <sjenning-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Vojtech Pavlik <vojtech-IBi9RG/b67k@public.gmane.org>,
	Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
	Miroslav Benes <mbenes-AlSwsSmVLrQ@public.gmane.org>,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: module: preserve Elf information for livepatch modules
Date: Mon, 8 Feb 2016 15:34:42 -0500	[thread overview]
Message-ID: <20160208203441.GB27290@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <20160208201039.GC23106-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>

+++ Josh Poimboeuf [08/02/16 14:10 -0600]:
>On Wed, Feb 03, 2016 at 08:11:07PM -0500, Jessica Yu wrote:
>> For livepatch modules, copy Elf section, symbol, and string information
>> from the load_info struct in the module loader. Persist copies of the
>> original symbol table and string table.
>>
>> Livepatch manages its own relocation sections in order to reuse module
>> loader code to write relocations. Livepatch modules must preserve Elf
>> information such as section indices in order to apply livepatch relocation
>> sections using the module loader's apply_relocate_add() function.
>>
>> In order to apply livepatch relocation sections, livepatch modules must
>> keep a complete copy of their original symbol table in memory. Normally, a
>> stripped down copy of a module's symbol table (containing only "core"
>> symbols) is made available through module->core_symtab. But for livepatch
>> modules, the symbol table copied into memory on module load must be exactly
>> the same as the symbol table produced when the patch module was compiled.
>> This is because the relocations in each livepatch relocation section refer
>> to their respective symbols with their symbol indices, and the original
>> symbol indices (and thus the symtab ordering) must be preserved in order
>> for apply_relocate_add() to find the right symbol.
>
>This patch didn't apply clean to linux-next/master.  I didn't
>investigate why, but maybe it depends on the other patch set which
>removes the notifiers?  (If so, that should be mentioned in the cover
>letter.)

A very recent commit (8244062ef) introduced some changes
kernel/module.c that intersect with this patch, so I think this is why
the patch didn't apply cleanly to today's tree...Anyhow I will rebase
again before sending out v5. Thanks for the comments :-)

Jessica

  reply	other threads:[~2016-02-08 20:34 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04  1:11 [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-02-04  1:11 ` Jessica Yu
2016-02-04  1:11 ` [RFC PATCH v4 1/6] Elf: add livepatch-specific Elf constants Jessica Yu
2016-02-04  1:11   ` Jessica Yu
2016-02-04  1:11 ` [RFC PATCH v4 2/6] module: preserve Elf information for livepatch modules Jessica Yu
2016-02-08 20:10   ` Josh Poimboeuf
2016-02-08 20:34     ` Jessica Yu [this message]
2016-02-08 20:34       ` Jessica Yu
2016-02-09  8:44   ` [RFC PATCH v4 2/6] " Petr Mladek
2016-02-09  8:44     ` Petr Mladek
2016-02-09 10:33     ` Jiri Kosina
2016-02-09 12:31       ` Petr Mladek
2016-02-09 12:31         ` Petr Mladek
2016-02-10  0:18         ` Rusty Russell
2016-02-10 15:53   ` Petr Mladek
2016-02-04  1:11 ` [RFC PATCH v4 3/6] module: s390: keep mod_arch_specific " Jessica Yu
2016-02-04  1:37   ` Jessica Yu
2016-02-04 21:03     ` Josh Poimboeuf
2016-02-05 15:32       ` Miroslav Benes
2016-02-04  1:11 ` [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-02-08 15:05   ` Miroslav Benes
2016-02-09 13:32     ` Miroslav Benes
2016-02-08 20:26   ` Josh Poimboeuf
2016-02-08 20:26     ` Josh Poimboeuf
2016-02-10  0:56     ` Jessica Yu
2016-02-10  0:56       ` Jessica Yu
2016-02-09 14:01   ` [RFC PATCH v4 4/6] " Petr Mladek
2016-02-09 14:01     ` Petr Mladek
2016-02-09 15:57     ` Miroslav Benes
2016-02-10  1:21     ` Jessica Yu
2016-02-04  1:11 ` [RFC PATCH v4 5/6] samples: livepatch: mark as livepatch module Jessica Yu
2016-02-04  1:11 ` [RFC PATCH v4 6/6] Documentation: livepatch: outline Elf format and requirements for patch modules Jessica Yu
2016-02-08 14:54 ` [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Miroslav Benes
2016-02-08 20:28   ` Josh Poimboeuf
2016-02-08 20:28     ` Josh Poimboeuf
2016-02-09 15:56 ` Petr Mladek
  -- strict thread matches above, loose matches on Subject: below --
2016-03-16 19:47 [PATCH v5 " Jessica Yu
2016-03-16 19:47 ` [PATCH v5 2/6] module: preserve Elf information for livepatch modules Jessica Yu
2016-03-16 21:25   ` Jessica Yu
2016-03-16 21:25     ` Jessica Yu
2016-03-21 14:06   ` [PATCH v5 2/6] " Josh Poimboeuf
2016-03-22 17:57     ` Jessica Yu
2016-03-22 17:57       ` Jessica Yu
2016-03-22 18:55       ` Josh Poimboeuf
2016-03-22 18:55         ` Josh Poimboeuf
2016-01-08 19:28 [RFC PATCH v3 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-01-08 19:28 ` [RFC PATCH v3 2/6] module: preserve Elf information for livepatch modules Jessica Yu
2016-01-11  1:25   ` Rusty Russell
2016-01-14  4:47     ` Jessica Yu
2016-01-14 20:28       ` Rusty Russell
2016-01-14 20:28         ` Rusty Russell
2015-12-01  4:21 [RFC PATCH v2 0/6] (mostly) Arch-independent livepatch Jessica Yu
2015-12-01  4:21 ` [RFC PATCH v2 2/6] module: preserve Elf information for livepatch modules Jessica Yu
2015-12-01  8:48   ` Jessica Yu
2015-12-01  8:48     ` Jessica Yu
2015-12-01 21:06   ` Jessica Yu
2015-12-08 18:32   ` [RFC PATCH v2 2/6] " Josh Poimboeuf
2015-12-09 20:05     ` Jessica Yu
2015-12-09 20:05       ` Jessica Yu
2015-12-10 14:38       ` Josh Poimboeuf
2015-12-16 10:46         ` Miroslav Benes
2015-12-16 10:46           ` Miroslav Benes
2015-12-16 10:58   ` [RFC PATCH v2 2/6] " Miroslav Benes
2015-12-17  0:40     ` Jessica Yu
2015-12-17 16:26   ` [RFC PATCH v2 2/6] " Petr Mladek
2015-12-21  5:44     ` Jessica Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160208203441.GB27290@packer-debian-8-amd64.digitalocean.com \
    --to=jeyu@redhat.com \
    --cc=corbet@lwn.net \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=rusty@rustcorp.com.au \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.