All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Jessica Yu <jeyu@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Petr Mladek <pmladek@suse.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
	linux-api@vger.kernel.org, live-patching@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: module: save load_info for livepatch modules
Date: Fri, 13 Nov 2015 13:24:32 +0100 (CET)	[thread overview]
Message-ID: <alpine.LNX.2.00.1511131304280.15073@pobox.suse.cz> (raw)
In-Reply-To: <20151112221750.GA13513@packer-debian-8-amd64.digitalocean.com>

On Thu, 12 Nov 2015, Jessica Yu wrote:

> +++ Josh Poimboeuf [12/11/15 11:05 -0600]:
> > On Thu, Nov 12, 2015 at 04:03:45PM +0100, Petr Mladek wrote:
> > > On Thu 2015-11-12 14:22:28, Miroslav Benes wrote:
> > > > On Thu, 12 Nov 2015, Petr Mladek wrote:
> > > > > > >Maybe I am missing something but isn't it necessary to call vfree()
> > > on
> > > > > > >info somewhere in the end?
> > > > > >
> > > > > > So free_copy() will call vfree(info->hdr), except in livepatch
> > > modules
> > > > > > we want to keep all the elf section information stored there, so we
> > > > > > avoid calling free_copy(), As for the info struct itself, if you
> > > look
> > > > > > at the init_module and finit_module syscall definitions in
> > > > > > kernel/module.c, you will see that info is actually a local function
> > > > > > variable, simply passed in to the call to load_module(), and will be
> > > > > > automatically deallocated when the syscall returns. :-) No need to
> > > > > > explicitly free info.
> > > > >
> > > > > We still have to free the copied or preserved structures when
> > > > > the module is unloaded.
> > > >
> > > > ...freeing what we allocated. We need to free info->hdr somewhere if not
> > > > here and also mod_arch_specific struct where the patch module is
> > > removed.
> > > > This would unfortunately lead to changes in arch-specific code in
> > > > module.c. For example in arch/s390/kernel/module.c there is vfree call
> > > on
> > > > part of mod_arch_specific in module_finalize. We would call it only if
> > > the
> > > > flag mentioned above is not set and at the same time we would need to
> > > call
> > > > it when the patch module is being removed.
> > > 
> > > Sigh, I am afraid that the flag is not enough. IMHO, we need to split
> > > the load finalizing functions into two pieces. One will be always
> > > called when the module load is finalized. The other part will free
> > > the load_info. It will be called either when the load is finalized or
> > > when the module is unloaded, depending on if we want to preserve
> > > the load_info.
> > > 
> > > Sigh, it is getting complicated. But let's see how it looks in reality.
> > 
> > At the other end of the spectrum, we could do the simplest thing
> > possible: _always_ save the data (even if CONFIG_LIVEPATCH is disabled).
> > 
> > (gdb) print sizeof(*info)
> > $3 = 96
> > (gdb) p sizeof(*info->hdr)
> > $4 = 64
> > s390 mod_arch_syminfo struct: 24 bytes by my reckoning.
> > 
> > So between info, info->hdr, and s390 mod_arch_syminfo, we're talking
> > about 184 bytes on s390 and 160 bytes on x86_64.  That seems like
> > peanuts compared to the size of a typical module.  The benefit is that
> > the code would be simpler because we don't have any special cases and
> > the structs would automatically get freed with the module struct when
> > the module gets unloaded.

Agreed. mod_arch_specific contains more things on certain architectures, 
but compared to the size of a module it is still not much.

> 
> I think I agree with Josh on this one (except, I would always save
> load_info if it is a livepatch module, instead of for every module in the
> !CONFIG_LIVEPATCH case, and we can just check modinfo to see if it is
> a livepatch module).
> 
> If the tradeoff here is between simplicity and readibility of code vs.
> saving some extra space (and by the looks of it, not a lot), I think I
> would choose having clear code over saving some bytes of memory. Hard
> coding checks and edge cases imo might cause confusion and trouble
> down the road.

I agree this seems like the best approach. So if we preserve 
mod_arch_syminfo (in case of s390) we should free it not in 
module_finalize, but somewhere in free_module... where 
module_arch_cleanup() is called... and also module_arch_freeing_init() is 
called there too. And what you find there for s390 is 

	vfree(mod->arch.syminfo);
	mod->arch.syminfo = NULL;

Well, it does nothing here, because mod->arch.syminfo is already NULL. It 
was freed in module_finalize. So we can even remove this code from 
module_finalize and all should be fine. At least for s390.

As for load_info, I don't have a strong opinion whether to keep it for all 
modules or for livepatch modules only.

Miroslav

WARNING: multiple messages have this Message-ID (diff)
From: Miroslav Benes <mbenes-AlSwsSmVLrQ@public.gmane.org>
To: Jessica Yu <jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Josh Poimboeuf <jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>,
	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>,
	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
Subject: Re: module: save load_info for livepatch modules
Date: Fri, 13 Nov 2015 13:24:32 +0100 (CET)	[thread overview]
Message-ID: <alpine.LNX.2.00.1511131304280.15073@pobox.suse.cz> (raw)
In-Reply-To: <20151112221750.GA13513-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>

On Thu, 12 Nov 2015, Jessica Yu wrote:

> +++ Josh Poimboeuf [12/11/15 11:05 -0600]:
> > On Thu, Nov 12, 2015 at 04:03:45PM +0100, Petr Mladek wrote:
> > > On Thu 2015-11-12 14:22:28, Miroslav Benes wrote:
> > > > On Thu, 12 Nov 2015, Petr Mladek wrote:
> > > > > > >Maybe I am missing something but isn't it necessary to call vfree()
> > > on
> > > > > > >info somewhere in the end?
> > > > > >
> > > > > > So free_copy() will call vfree(info->hdr), except in livepatch
> > > modules
> > > > > > we want to keep all the elf section information stored there, so we
> > > > > > avoid calling free_copy(), As for the info struct itself, if you
> > > look
> > > > > > at the init_module and finit_module syscall definitions in
> > > > > > kernel/module.c, you will see that info is actually a local function
> > > > > > variable, simply passed in to the call to load_module(), and will be
> > > > > > automatically deallocated when the syscall returns. :-) No need to
> > > > > > explicitly free info.
> > > > >
> > > > > We still have to free the copied or preserved structures when
> > > > > the module is unloaded.
> > > >
> > > > ...freeing what we allocated. We need to free info->hdr somewhere if not
> > > > here and also mod_arch_specific struct where the patch module is
> > > removed.
> > > > This would unfortunately lead to changes in arch-specific code in
> > > > module.c. For example in arch/s390/kernel/module.c there is vfree call
> > > on
> > > > part of mod_arch_specific in module_finalize. We would call it only if
> > > the
> > > > flag mentioned above is not set and at the same time we would need to
> > > call
> > > > it when the patch module is being removed.
> > > 
> > > Sigh, I am afraid that the flag is not enough. IMHO, we need to split
> > > the load finalizing functions into two pieces. One will be always
> > > called when the module load is finalized. The other part will free
> > > the load_info. It will be called either when the load is finalized or
> > > when the module is unloaded, depending on if we want to preserve
> > > the load_info.
> > > 
> > > Sigh, it is getting complicated. But let's see how it looks in reality.
> > 
> > At the other end of the spectrum, we could do the simplest thing
> > possible: _always_ save the data (even if CONFIG_LIVEPATCH is disabled).
> > 
> > (gdb) print sizeof(*info)
> > $3 = 96
> > (gdb) p sizeof(*info->hdr)
> > $4 = 64
> > s390 mod_arch_syminfo struct: 24 bytes by my reckoning.
> > 
> > So between info, info->hdr, and s390 mod_arch_syminfo, we're talking
> > about 184 bytes on s390 and 160 bytes on x86_64.  That seems like
> > peanuts compared to the size of a typical module.  The benefit is that
> > the code would be simpler because we don't have any special cases and
> > the structs would automatically get freed with the module struct when
> > the module gets unloaded.

Agreed. mod_arch_specific contains more things on certain architectures, 
but compared to the size of a module it is still not much.

> 
> I think I agree with Josh on this one (except, I would always save
> load_info if it is a livepatch module, instead of for every module in the
> !CONFIG_LIVEPATCH case, and we can just check modinfo to see if it is
> a livepatch module).
> 
> If the tradeoff here is between simplicity and readibility of code vs.
> saving some extra space (and by the looks of it, not a lot), I think I
> would choose having clear code over saving some bytes of memory. Hard
> coding checks and edge cases imo might cause confusion and trouble
> down the road.

I agree this seems like the best approach. So if we preserve 
mod_arch_syminfo (in case of s390) we should free it not in 
module_finalize, but somewhere in free_module... where 
module_arch_cleanup() is called... and also module_arch_freeing_init() is 
called there too. And what you find there for s390 is 

	vfree(mod->arch.syminfo);
	mod->arch.syminfo = NULL;

Well, it does nothing here, because mod->arch.syminfo is already NULL. It 
was freed in module_finalize. So we can even remove this code from 
module_finalize and all should be fine. At least for s390.

As for load_info, I don't have a strong opinion whether to keep it for all 
modules or for livepatch modules only.

Miroslav

  reply	other threads:[~2015-11-13 12:24 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  4:45 [RFC PATCH 0/5] Arch-independent livepatch Jessica Yu
2015-11-10  4:45 ` Jessica Yu
2015-11-10  4:45 ` [RFC PATCH 1/5] elf: add livepatch-specific elf constants Jessica Yu
2015-11-11 13:58   ` Petr Mladek
2015-11-12 15:33   ` Josh Poimboeuf
2015-11-12 15:45   ` Josh Poimboeuf
2015-11-13  6:49     ` Jessica Yu
2015-11-10  4:45 ` [RFC PATCH 2/5] module: save load_info for livepatch modules Jessica Yu
2015-11-11  8:08   ` Minfei Huang
2015-11-11 14:17   ` Miroslav Benes
2015-11-12  5:33     ` Jessica Yu
2015-11-12 10:24       ` Petr Mladek
2015-11-12 13:22         ` Miroslav Benes
2015-11-12 13:22           ` Miroslav Benes
2015-11-12 15:03           ` Petr Mladek
2015-11-12 15:03             ` Petr Mladek
2015-11-12 17:05             ` Josh Poimboeuf
2015-11-12 17:05               ` Josh Poimboeuf
2015-11-12 22:17               ` Jessica Yu
2015-11-12 22:17                 ` Jessica Yu
2015-11-13 12:24                 ` Miroslav Benes [this message]
2015-11-13 12:24                   ` Miroslav Benes
2015-11-13 12:46                   ` Miroslav Benes
2015-11-13 12:46                     ` Miroslav Benes
2015-11-14  0:36                     ` Jessica Yu
2015-11-14  0:36                       ` Jessica Yu
2015-11-16 12:12                       ` Miroslav Benes
2015-11-16 12:12                         ` Miroslav Benes
2015-11-13 12:56                   ` Miroslav Benes
2015-11-13 12:56                     ` Miroslav Benes
2015-11-14  2:09                     ` Jessica Yu
2015-11-14  2:09                       ` Jessica Yu
2015-11-16 12:21                       ` Miroslav Benes
2015-11-16 12:21                         ` Miroslav Benes
2015-11-13  0:25           ` Jessica Yu
2015-11-11 14:31   ` [RFC PATCH 2/5] " Petr Mladek
2015-11-11 14:31     ` Petr Mladek
2015-11-12  4:44     ` Jessica Yu
2015-11-12  4:44       ` Jessica Yu
2015-11-12 10:05       ` Petr Mladek
2015-11-12 10:05         ` Petr Mladek
2015-11-12 14:19         ` Miroslav Benes
2015-11-12 14:19           ` Miroslav Benes
2015-11-13  6:35           ` Jessica Yu
2015-11-13  6:35             ` Jessica Yu
2015-11-13 13:07             ` Miroslav Benes
2015-11-13  8:20         ` Jessica Yu
2015-11-13  8:20           ` Jessica Yu
2015-11-12 17:14   ` [RFC PATCH 2/5] " Josh Poimboeuf
2015-11-12 17:14     ` Josh Poimboeuf
2015-11-12 17:21   ` Josh Poimboeuf
2015-11-12 17:21     ` Josh Poimboeuf
2015-11-10  4:45 ` [RFC PATCH 3/5] livepatch: reuse module loader code to write relocations Jessica Yu
2015-11-10  8:13   ` Jiri Slaby
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
2015-11-12 17:59   ` [RFC PATCH 3/5] " Josh Poimboeuf
2015-11-12 17:59     ` Josh Poimboeuf
2015-11-10  4:45 ` [RFC PATCH 4/5] samples: livepatch: init reloc list and mark as klp module Jessica Yu
2015-11-10  8:15   ` Jiri Slaby
2015-11-10  8:15     ` Jiri Slaby
2015-11-10 13:50     ` Josh Poimboeuf
2015-11-10 18:37       ` Jessica Yu
2015-11-10 18:37         ` Jessica Yu
2015-11-11 15:42   ` [RFC PATCH 4/5] " Petr Mladek
2015-11-11 15:42     ` Petr Mladek
2015-11-12  6:02     ` Jessica Yu
2015-11-12  6:02       ` Jessica Yu
2015-11-12 10:44       ` Miroslav Benes
2015-11-12 10:44         ` Miroslav Benes
2015-11-10  4:45 ` [RFC PATCH 5/5] livepatch: x86: remove unused relocation code Jessica Yu
2015-11-11 15:48   ` Petr Mladek
2015-11-12 18:01     ` Josh Poimboeuf
2015-11-11 14:00 ` [RFC PATCH 0/5] Arch-independent livepatch Miroslav Benes
2015-11-11 16:28   ` Josh Poimboeuf

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.1511131304280.15073@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=pmladek@suse.com \
    --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.