linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Petr Mladek <pmladek@suse.com>
Cc: jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	jbaron@akamai.com
Subject: Re: [PATCH 1/2] livepatch: Remove immediate feature
Date: Fri, 22 Dec 2017 14:10:37 +0100 (CET)	[thread overview]
Message-ID: <alpine.LSU.2.21.1712221404240.25210@pobox.suse.cz> (raw)
In-Reply-To: <20171221145812.ijs4epzvwbbthxk5@pathway.suse.cz>

On Thu, 21 Dec 2017, Petr Mladek wrote:

> Hello,
> 
> it seems that we are going to use this patch (I agree). Therefore
> I am going to review the content.
> 
> On Fri 2017-12-08 18:25:22, Miroslav Benes wrote:
> > immediate flag has been used to disable per-task consistency and patch
> > all tasks immediately. It could be useful if the patch doesn't change any
> > function or data semantics.
> > 
> > However, it causes problems on its own. The consistency problem is
> > currently broken with respect to immediate patches.
> > 
> > func            a
> > patches         1i
> >                 2i
> >                 3
> > 
> > When the patch 3 is applied, only 2i function is checked (by stack
> > checking facility). There might be a task sleeping in 1i though. Such
> > task is migrated to 3, because we do not check 1i in
> > klp_check_stack_func() at all.
> > 
> > Coming atomic replace feature would be easier to implement and more
> > reliable without immediate.
> > 
> > Moreover, the fake signal and force feature give us almost the same
> > benefits and the user can decide to use them in problematic situations
> > (while immediate needs to be set before the patch is applied). It is
> > also more isolated in terms of code.
> > 
> > Thus, remove immediate feature completely and save us from the problems.
> 
> Just for record, the above paragraphs needs to be reworded because the
> problem still will be there with the force feature.

Yes, the changelog should be rewritten.
 
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index 1c3c9b27c916..461c0b7dc913 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -367,10 +367,10 @@ static int __klp_enable_patch(struct klp_patch *patch)
> >  	 * A reference is taken on the patch module to prevent it from being
> >  	 * unloaded.
> >  	 *
> > -	 * Note: For immediate (no consistency model) patches we don't allow
> > -	 * patch modules to unload since there is no safe/sane method to
> > -	 * determine if a thread is still running in the patched code contained
> > -	 * in the patch module once the ftrace registration is successful.
> > +	 * Note: When klp_forced is set we don't allow patch modules to unload
> > +	 * since there is no safe/sane method to determine if a thread is still
> > +	 * running in the patched code contained in the patch module once the
> > +	 * ftrace registration is successful.
> 
> I would remove this paragraph completely. You removed the
> cross-reference klp_complete_transition() as well.

Ok.

> >  	 */
> >  	if (!try_module_get(patch->mod))
> >  		return -ENODEV;
> > @@ -890,12 +890,7 @@ int klp_register_patch(struct klp_patch *patch)
> >  	if (!klp_initialized())
> >  		return -ENODEV;
> >  
> > -	/*
> > -	 * Architectures without reliable stack traces have to set
> > -	 * patch->immediate because there's currently no way to patch kthreads
> > -	 * with the consistency model.
> > -	 */
> > -	if (!klp_have_reliable_stack() && !patch->immediate) {
> > +	if (!klp_have_reliable_stack()) {
> >  		pr_err("This architecture doesn't have support for the livepatch consistency model.\n");
> >  		return -ENOSYS;
> >  	}
> 
> > diff --git a/samples/livepatch/livepatch-callbacks-demo.c b/samples/livepatch/livepatch-callbacks-demo.c
> > index 3d115bd68442..bda7f3841f3e 100644
> > --- a/samples/livepatch/livepatch-callbacks-demo.c
> > +++ b/samples/livepatch/livepatch-callbacks-demo.c
> > @@ -197,20 +197,8 @@ static int livepatch_callbacks_demo_init(void)
> >  {
> >  	int ret;
> >  
> > -	if (!klp_have_reliable_stack() && !patch.immediate) {
> > -		/*
> > -		 * WARNING: Be very careful when using 'patch.immediate' in
> > -		 * your patches.  It's ok to use it for simple patches like
> > -		 * this, but for more complex patches which change function
> > -		 * semantics, locking semantics, or data structures, it may not
> > -		 * be safe.  Use of this option will also prevent removal of
> > -		 * the patch.
> > -		 *
> > -		 * See Documentation/livepatch/livepatch.txt for more details.
> > -		 */
> > -		patch.immediate = true;
> > -		pr_notice("The consistency model isn't supported for your architecture.  Bypassing safety mechanisms and applying the patch immediately.\n");
> > -	}
> > +	if (!klp_have_reliable_stack())
> > +		pr_notice("The consistency model isn't supported for your architecture. The transition may not finish.\n");
> 
> The notice is redundant. The klp_registrer_patch() would printk
> similar message and return -ENOSYS.
> 
> Same is true for the other sample modules.

Yes. I wanted the patch to be a mechanic removal of immediate and do the 
rest somewhere else. But that did not work out anyway, so ok.
 
> In each case, I like this patch. It simplifies the code a lot.

Yes. Thanks.

Miroslav

  reply	other threads:[~2017-12-22 13:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 17:25 [PATCH 0/2] Remove immediate feature Miroslav Benes
2017-12-08 17:25 ` [PATCH 1/2] livepatch: " Miroslav Benes
2017-12-20 14:35   ` Petr Mladek
2017-12-20 17:09     ` Josh Poimboeuf
2017-12-21 13:30       ` Petr Mladek
2017-12-21 13:55         ` Miroslav Benes
2017-12-21 14:58   ` Petr Mladek
2017-12-22 13:10     ` Miroslav Benes [this message]
2017-12-08 17:25 ` [PATCH 2/2] livepatch: Allow loading modules on architectures without HAVE_RELIABLE_STACKTRACE Miroslav Benes
2017-12-21 15:14   ` Petr Mladek
2017-12-22 13:12     ` Miroslav Benes

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.LSU.2.21.1712221404240.25210@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=jbaron@akamai.com \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=pmladek@suse.com \
    /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;
as well as URLs for NNTP newsgroup(s).