mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.cz>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Seth Jennings <sjenning@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.cz>,
	Steven Rostedt <rostedt@goodmis.org>,
	Christoph Hellwig <hch@infradead.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	live-patching@vger.kernel.org, x86@kernel.org, kpatch@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] livepatch: clean up klp_find_object_module() usage: was: Re: [PATCHv4 2/3] kernel: add support for live patching
Date: Mon, 1 Dec 2014 13:40:55 +0100	[thread overview]
Message-ID: <20141201124055.GB18532@pathway.suse.cz> (raw)
In-Reply-To: <alpine.LNX.2.00.1412011256420.23443@pobox.suse.cz>

On Mon 2014-12-01 13:08:50, Miroslav Benes wrote:
> On Fri, 28 Nov 2014, Petr Mladek wrote:
> 
> > On Fri 2014-11-28 18:07:37, Petr Mladek wrote:
> > > On Tue 2014-11-25 11:15:08, Seth Jennings wrote:
> > > > This commit introduces code for the live patching core.  It implements
> > > > an ftrace-based mechanism and kernel interface for doing live patching
> > > > of kernel and kernel module functions.
> > 
> > [...]
> > 
> > > > +/* sets obj->mod if object is not vmlinux and module is found */
> > > > +static bool klp_find_object_module(struct klp_object *obj)
> > > > +{
> > > > +	if (!obj->name)
> > > > +		return 1;
> > > > +
> > > > +	mutex_lock(&module_mutex);
> > > > +	/*
> > > > +	 * We don't need to take a reference on the module here because we have
> > > > +	 * the klp_mutex, which is also taken by the module notifier.  This
> > > > +	 * prevents any module from unloading until we release the klp_mutex.
> > > > +	 */
> > > > +	obj->mod = find_module(obj->name);
> > > > +	mutex_unlock(&module_mutex);
> > > > +
> > > > +	return !!obj->mod;
> > > 
> > > I know that this is effective to return boolean here because
> > > it handles also patch against the kernel core (vmlinux). But
> > > the logic looks tricky. I would prefer a cleaner design and
> > > use this function only to set obj->mod.
> > > 
> > > I wanted to see how it would look like, so I will send a patch for
> > > this in a separate mail.
> > 
> > The patch is below. Of course, merge it into the original
> > patch if you agree with the idea, please.
> > 
> > 
> > >From 93eb9f9a25ad8aa0301e246f7685d3e787037566 Mon Sep 17 00:00:00 2001
> > From: Petr Mladek <pmladek@suse.cz>
> > Date: Fri, 28 Nov 2014 15:32:27 +0100
> > Subject: [PATCH 1/2] livepatch: clean up klp_find_object_module() usage
> > 
> > The function klp_find_object_module() looks quite tricky. It has two effects:
> > sets obj->mod and decides whether the module is available or not. The second
> > effect is the tricky part because it handles also the code kernel code "vmlinux"
> > and is not module related. It causes returning bool, and doing the crazy double
> > negation.
> > 
> > This patch tries to make a bit cleaner design:
> > 
> > 1. klp_find_object_module() handles only obj->mod. It returns
> >    the pointer or NULL.
> > 
> > 2. It modifies klp_enable_object() to do nothing when the related
> >    module has not been loaded yet.
> > 
> > 3. The result is that the return value klp_find_object_module() is
> >    not used in the end.
> > 
> > We lose a check for potential klp_enable_object() misuse but it makes the code
> > easier. In fact, the check for unloaded module is rather long. We might want
> > to make it easier using some extra flag or another state of the object.
> > Such flag might be used for the check of misuse.
> > 
> > Signed-off-by: Petr Mladek <pmladek@suse.cz>
> 
> Hi, 
> 
> I agree with the idea but actually don't like the implementation. I'll try 
> to propose few changes which would hopefully preserve the effect but make 
> the end result slightly better.
> 
> > ---
> >  kernel/livepatch/core.c | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index 8e2e8cd242f5..9b1601729014 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -40,10 +40,10 @@ static LIST_HEAD(klp_patches);
> >  static struct kobject *klp_root_kobj;
> >  
> >  /* sets obj->mod if object is not vmlinux and module is found */
> > -static bool klp_find_object_module(struct klp_object *obj)
> > +static struct module *klp_find_object_module(struct klp_object *obj)
> >  {
> >  	if (!obj->name)
> > -		return 1;
> > +		return NULL;
> >  
> >  	mutex_lock(&module_mutex);
> >  	/*
> > @@ -54,7 +54,7 @@ static bool klp_find_object_module(struct klp_object *obj)
> >  	obj->mod = find_module(obj->name);
> >  	mutex_unlock(&module_mutex);
> >  
> > -	return !!obj->mod;
> > +	return obj->mod;
> >  }
> 
> As we do not need the return value in the end, we could maybe drop it 
> completely, leading to change in if condition
> 
> 	if (!obj->name)
> 		return;

Sounds good.

> >  struct klp_find_arg {
> > @@ -318,8 +318,9 @@ static int klp_enable_object(struct module *pmod, struct klp_object *obj)
> >  	struct klp_func *func;
> >  	int ret;
> >  
> > -	if (WARN_ON(!obj->mod && obj->name))
> > -		return -EINVAL;
> > +	/* nope when the patched module has not been loaded yet */
> > +	if (obj->name && !obj->mod)
> > +		return 0;
> 
> I have a problem with this one. In case the condition is true we do 
> nothing, return back and pretend that everything is alright (return 0). 
> I see that we would call klp_enable_object everytime in your proposal and 
> decide here whether we want to do something or not. But I think that we 
> should return some error and deal with it in the caller function. Thus 
> original WARN_ON should stay here.

I agree.


> >  	if (obj->relocs) {
> >  		ret = klp_write_object_relocations(pmod, obj);
> > @@ -401,8 +402,7 @@ static int __klp_enable_patch(struct klp_patch *patch)
> >  	pr_notice("enabling patch '%s'\n", patch->mod->name);
> >  
> >  	for (obj = patch->objs; obj->funcs; obj++) {
> > -		if (!klp_find_object_module(obj))
> > -			continue;
> > +		klp_find_object_module(obj);
> >  		ret = klp_enable_object(patch->mod, obj);
> >  		if (ret)
> >  			goto unregister;
> 
> I propose this piece of code
> 
> for (obj = patch->objs; obj->funcs; obj++) {
> 	klp_find_object_module(obj);
> 	if (obj->name && !obj->mod)
> 		continue;
> 	ret = klp_enable_object(patch->mod, obj);
> 	...
> }

I like this change, especially if we replace the condition with a
macro. It keeps klp_find_object_module() without the side effect
and it keeps the warning in klp_enable_object().


> What do you think? Also it could pay off to define inline function for the 
> check. Somethink like klp_is_module_and_loaded...

klp_is_object_loaded() is easier and still clear. Also we might want
to add a macro klp_is_module(obj).

Best Regards,
Petr

  reply	other threads:[~2014-12-01 12:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 17:15 [PATCHv4 0/3] Kernel Live Patching Seth Jennings
2014-11-25 17:15 ` [PATCHv4 1/3] kernel: add TAINT_LIVEPATCH Seth Jennings
2014-11-25 17:15 ` [PATCHv4 2/3] kernel: add support for live patching Seth Jennings
2014-11-26  9:05   ` Masami Hiramatsu
2014-11-26 13:37   ` Jiri Slaby
2014-11-26 14:19   ` Miroslav Benes
2014-11-26 15:40     ` Josh Poimboeuf
2014-12-01 13:31       ` Miroslav Benes
2014-12-01 17:07         ` Josh Poimboeuf
2014-12-02 12:24           ` Miroslav Benes
2014-11-28 17:07   ` Petr Mladek
2014-11-28 17:14     ` [PATCH] livepatch: clean up klp_find_object_module() usage: was: " Petr Mladek
2014-12-01 12:08       ` Miroslav Benes
2014-12-01 12:40         ` Petr Mladek [this message]
2014-11-28 17:19     ` [PATCH] livepatch: do relocation when initializing the patch: " Petr Mladek
2014-12-03 10:00   ` Miroslav Benes
2014-11-25 17:15 ` [PATCHv4 3/3] samples: add sample live patching module Seth Jennings
2014-11-27 17:05   ` Petr Mladek
2014-12-01 17:11     ` Seth Jennings
2014-11-25 19:26 ` [PATCHv4 0/3] Kernel Live Patching Jiri Kosina
2014-11-25 22:10   ` Seth Jennings
2014-11-25 22:22     ` Jiri Kosina
2014-11-26  9:00 ` Masami Hiramatsu
2014-11-26  9:18   ` Jiri Kosina
2014-11-26  9:26     ` Jiri Kosina
2014-11-26 15:27     ` Josh Poimboeuf
2014-11-27 10:06       ` Masami Hiramatsu
2014-11-27 10:52         ` Petr Mladek
2014-11-28  2:21           ` Masami Hiramatsu
2014-11-27  6:12     ` Masami Hiramatsu
2014-11-26 15:55   ` 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=20141201124055.GB18532@pathway.suse.cz \
    --to=pmladek@suse.cz \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=kpatch@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mbenes@suse.cz \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®