All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.cz>
Cc: Minfei Huang <mnfhuang@gmail.com>,
	mbenes@suse.cz, sjenning@redhat.com, jkosina@suse.cz,
	vojtech@suse.cz, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org, mhuang@redhat.com
Subject: Re: [PATCH v3] livepatch: Prevent to apply the patch once coming module notifier fails
Date: Mon, 18 May 2015 10:59:54 -0500	[thread overview]
Message-ID: <20150518155954.GB8995@treble.redhat.com> (raw)
In-Reply-To: <20150518155052.GG2632@pathway.suse.cz>

On Mon, May 18, 2015 at 05:50:52PM +0200, Petr Mladek wrote:
> On Mon 2015-05-18 10:22:21, Josh Poimboeuf wrote:
> > On Mon, May 18, 2015 at 02:08:06PM +0200, Petr Mladek wrote:
> > > On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
> > > > On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
> > > > > @@ -930,6 +932,7 @@ disabled:
> > > > >  static int klp_module_notify(struct notifier_block *nb, unsigned long action,
> > > > >  			     void *data)
> > > > >  {
> > > > > +	int ret;
> > > > >  	struct module *mod = data;
> > > > >  	struct klp_patch *patch;
> > > > >  	struct klp_object *obj;
> > > > > @@ -955,7 +958,13 @@ static int klp_module_notify(struct notifier_block *nb, unsigned long action,
> > > > >  
> > > > >  			if (action == MODULE_STATE_COMING) {
> > > > >  				obj->mod = mod;
> > > > > -				klp_module_notify_coming(patch, obj);
> > > > > +				ret = klp_module_notify_coming(patch, obj);
> > > > > +				if (ret) {
> > > > > +					obj->mod = NULL;
> > > > > +					pr_warn("patch '%s' is dead, remove it "
> > > > > +						"or re-install the module '%s'\n",
> > > > > +						patch->mod->name, obj->name);
> > > > > +				}
> > > > 
> > > > The patch isn't necessarily dead, since it might also include previously
> > > > enabled changes for vmlinux or other modules.  It can actually be a
> > > > dangerous condition if there's a mismatch between old code in the module
> > > > and new code elsewhere.  How about something like:
> > > > 
> > > > "patch '%s' is in an inconsistent state!\n"
> > > 
> > > It must not be dangerous, otherwise the patch could not get applied
> > > immediately.
> > >
> > > I would omit this message completely. It would just duplicate the
> > > warning printed by klp_module_notify_coming().
> > 
> > This error path doesn't mean that the entire patch isn't applied.  It
> > only affects the subset of the patch which applies to the coming module.
> > So you can have a dangerous mismatch in the case of a patch which
> > patches multiple objects.
> 
> We apply the patch immediately. This simple consistency model allows
> to call patched function from an upatched one and vice versa. It means
> that there must _not_ be any dependency between patched functions.
> And it means that it must be safe to keep the module unpatched.
> 
> The situation will change after we introduce a more complex
> consistency model. Then we will need to patch the module
> directly in load_module() and refuse loading in case of error.
> By other words, we will not and must not allow any dangerous state.
> 
> Does it make sense? Or did I miss anything, please?

Yeah, ok, that makes sense.  Given the simple consistency model, it's
not dangerous.  It's still inconsistent, and something the user should
know about, but perhaps a single warning in klp_module_notify_coming()
is enough.

I also agree that, once we have a better consistency model, failing to
load the module would be a better way to handle this error.

-- 
Josh

      reply	other threads:[~2015-05-18 16:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 14:04 [PATCH v3] livepatch: Prevent to apply the patch once coming module notifier fails Minfei Huang
2015-05-13 14:14 ` Josh Poimboeuf
2015-05-14  1:31   ` Minfei Huang
2015-05-18 12:08   ` Petr Mladek
2015-05-18 13:00     ` Minfei Huang
2015-05-18 15:35       ` Petr Mladek
2015-05-19  4:00         ` Minfei Huang
2015-05-18 15:22     ` Josh Poimboeuf
2015-05-18 15:50       ` Petr Mladek
2015-05-18 15:59         ` Josh Poimboeuf [this message]

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=20150518155954.GB8995@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mhuang@redhat.com \
    --cc=mnfhuang@gmail.com \
    --cc=pmladek@suse.cz \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.cz \
    /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.