All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Jessica Yu <jeyu@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
	Jonathan Corbet <corbet@lwn.net>,
	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: livepatch: reuse module loader code to write relocations
Date: Thu, 14 Jan 2016 10:04:11 +0100 (CET)	[thread overview]
Message-ID: <alpine.LNX.2.00.1601140958300.7127@pobox.suse.cz> (raw)
In-Reply-To: <20160114034933.GB980@packer-debian-8-amd64.digitalocean.com>

On Wed, 13 Jan 2016, Jessica Yu wrote:

> > Maybe it would be better to use pmod->symtab and pmod->strtab everywhere.
> > It should be the same, but core_* versions are only helpers used in
> > load_module and friends. There is even a comment in
> > include/linux/module.h.
> > 
> > 	/*
> > 	 * We keep the symbol and string tables for kallsyms.
> > 	 * The core_* fields below are temporary, loader-only (they
> > 	 * could really be discarded after module init).
> > 	 */
> > 
> > We should respect that.
> 
> I admit I'm a bit confused by the comment, I can't seem to find where
> core_symtab and core_strtab are purportedly discarded after module
> init (perhaps I'm missing something?). IMO it sounds more like it's
> describing mod->symtab and mod->strtab instead, because these are in
> module init memory and are freed later. 

I think it just says that core_* symbols are used as temporary tables 
during module loading. They are not discarded anywhere but they could be 
(and maybe they'll be in the future). So it is better not to depend on 
them.

> In any case, my reason for using
> core_symtab is that the original symbol table (mod->symtab) is marked
> with INIT_OFFSET_MASK in layout_symtab() (see kernel/module.c), and is
> therefore in init memory. This memory is freed near the end of
> do_init_module() with do_free_init(). Since core_symtab is in module core
> memory, for livepatch modules I simply used core_symtab to hold a
> full copy of the symbol table instead of the slimmed down version that
> it was originally intended to hold.

But both mod->symtab and mod->strtab are changed to point to their core_ 
versions right before do_free_init is called in do_init_module. So they 
should be the same. My remark was more of an academic question. I believe 
it is not a functional thing, just the matter of taste. But maybe I am 
missing something.

> Alternatively, we can tweak layout_symtab() to *not* mark the symtab
> with INIT_OFFSET_MASK and put it in core memory instead. I think
> either way will work, but maybe it is cleaner to do it this way
> instead.

Yeah, I wouldn't do this. core_* symbols are ok from functional point of 
view.

Thanks,
Miroslav

  reply	other threads:[~2016-01-14  9:04 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 19:28 [RFC PATCH v3 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-01-08 19:28 ` Jessica Yu
2016-01-08 19:28 ` [RFC PATCH v3 1/6] Elf: add livepatch-specific Elf constants 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-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
2016-01-08 19:28 ` [RFC PATCH v3 3/6] module: s390: keep mod_arch_specific " Jessica Yu
2016-01-08 19:28 ` [RFC PATCH v3 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-01-11 16:56   ` Petr Mladek
2016-01-11 16:56     ` Petr Mladek
2016-01-11 20:53     ` Josh Poimboeuf
2016-01-11 21:33   ` Josh Poimboeuf
2016-01-11 21:33     ` Josh Poimboeuf
2016-01-11 22:35     ` Jessica Yu
2016-01-11 22:35       ` Jessica Yu
2016-01-12  3:05       ` Josh Poimboeuf
2016-01-12  3:05         ` Josh Poimboeuf
2016-01-12  9:12         ` Petr Mladek
2016-01-12  9:12           ` Petr Mladek
2016-01-14  5:07         ` Jessica Yu
2016-01-14  5:07           ` Jessica Yu
2016-01-12 16:40   ` [RFC PATCH v3 4/6] " Miroslav Benes
2016-01-12 16:40     ` Miroslav Benes
2016-01-14  3:49     ` Jessica Yu
2016-01-14  9:04       ` Miroslav Benes [this message]
2016-01-13  9:19   ` [RFC PATCH v3 4/6] " Miroslav Benes
2016-01-13  9:31     ` Jiri Kosina
2016-01-13 18:39     ` Jessica Yu
2016-01-13 18:39       ` Jessica Yu
2016-01-14  9:10       ` Miroslav Benes
2016-01-08 19:28 ` [RFC PATCH v3 5/6] samples: livepatch: mark as livepatch module Jessica Yu
2016-01-08 19:28 ` [RFC PATCH v3 6/6] Documentation: livepatch: outline the Elf format of a " Jessica Yu
2016-01-08 19:28   ` Jessica Yu
2016-01-12 12:09   ` Petr Mladek
2016-01-12 14:45     ` Josh Poimboeuf
2016-01-14  5:04     ` Jessica Yu
2016-01-14  5:04       ` Jessica Yu
  -- strict thread matches above, loose matches on Subject: below --
2016-03-16 19:47 [PATCH v5 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-03-16 19:47 ` [PATCH v5 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-03-21 13:55   ` Miroslav Benes
2016-03-21 19:18     ` Jessica Yu
2016-03-21 19:24       ` Josh Poimboeuf
2016-03-21 21:16       ` Jiri Kosina
2016-03-21 21:34         ` Josh Poimboeuf
2016-03-21 22:02           ` Jiri Kosina
2016-03-21 22:02             ` Jiri Kosina
2016-03-22 19:00             ` Jessica Yu
2016-03-21 16:31   ` [PATCH v5 4/6] " Petr Mladek
2016-03-21 16:46     ` Josh Poimboeuf
2016-03-21 17:36       ` Josh Poimboeuf
2016-03-21 18:07         ` Jessica Yu
2016-02-04  1:11 [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-02-04  1:11 ` [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
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-10  1:21     ` Jessica Yu
2015-12-01  4:21 [RFC PATCH v2 0/6] (mostly) Arch-independent livepatch Jessica Yu
2015-12-01  4:21 ` [RFC PATCH v2 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2015-12-01  8:43   ` Jessica Yu
2015-12-01  8:43     ` Jessica Yu
2015-12-08 18:38   ` [RFC PATCH v2 4/6] " Josh Poimboeuf
2015-12-09 19:10     ` Jessica Yu
2015-12-09 19:10       ` Jessica Yu
2015-12-10 14:28       ` Josh Poimboeuf
2015-12-10 14:28         ` Josh Poimboeuf
2015-12-10 21:33         ` Jessica Yu
2015-12-10 21:41           ` Josh Poimboeuf
2015-12-10 21:41             ` Josh Poimboeuf
2015-12-10 22:07             ` Jessica Yu
2015-12-10 22:07               ` Jessica Yu
2015-12-16  5:40       ` Jessica Yu
2015-12-16  5:40         ` Jessica Yu
2015-12-16 12:59         ` Miroslav Benes
2015-12-16 19:14           ` Jessica Yu
2015-12-17 15:45         ` Petr Mladek
2015-12-17 15:45           ` Petr Mladek
2015-12-21  5:57           ` Jessica Yu
2015-11-10  4:45 [RFC PATCH 0/5] Arch-independent livepatch Jessica Yu
2015-11-10  4:45 ` [RFC PATCH 3/5] livepatch: reuse module loader code to write relocations Jessica Yu
2015-11-11 14:30   ` Miroslav Benes
2015-11-11 20:07     ` Jessica Yu
2015-11-11 20:07       ` Jessica Yu
2015-11-12 15:27       ` Miroslav Benes
2015-11-12 15:27         ` Miroslav Benes
2015-11-12 17:40         ` Josh Poimboeuf
2015-11-12 20:22           ` Jessica Yu
2015-11-12 20:22             ` Jessica Yu
2015-11-12 20:32             ` Josh Poimboeuf
2015-11-12 20:32               ` Josh Poimboeuf
2015-11-13  7:15               ` Jessica Yu
2015-11-13  7:15                 ` Jessica Yu
2015-11-13 13:51               ` Miroslav Benes
2015-11-12 19:14         ` Jessica Yu
2015-11-12 19:14           ` Jessica Yu
2015-11-12 20:35           ` Jessica Yu
2015-11-12 20:35             ` Jessica Yu
2015-11-11 15:22   ` [RFC PATCH 3/5] " Petr Mladek
2015-11-11 18:27     ` Jessica Yu
2015-11-11 18:27       ` Jessica Yu
2015-11-12  9:16       ` Petr Mladek
2015-11-12  9:16         ` Petr Mladek

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=alpine.LNX.2.00.1601140958300.7127@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=corbet@lwn.net \
    --cc=jeyu@redhat.com \
    --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=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.