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: Josh Poimboeuf <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: Thu, 21 Dec 2017 14:55:47 +0100 (CET)	[thread overview]
Message-ID: <alpine.LSU.2.21.1712211449330.7824@pobox.suse.cz> (raw)
In-Reply-To: <20171221133004.lilrqfiu3btb74lj@pathway.suse.cz>

On Thu, 21 Dec 2017, Petr Mladek wrote:

> On Wed 2017-12-20 11:09:37, Josh Poimboeuf wrote:
> > On Wed, Dec 20, 2017 at 03:35:12PM +0100, Petr Mladek wrote:
> > > 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.
> > > > 
> > > 
> > > Sigh, the force feature actually have the same problem. We would use
> > > it when a process never has a reliable stack or when it is endlessly
> > > sleeping in a function that might have been patched immediately.
> > > 
> > > I see two possibilities. We could either refuse loading new
> > > livepatches after using the force flag. Or we would need
> > > to check all variants of the function "a" that might still
> > > be in use.
> > 
> > "Using the force" is a nuclear option.  User beware.  If you use it (or
> > recommend that others use it), be prepared for the consequences.  That
> > means anticipating how forcing this patch might affect future patches,
> > and planning accordingly.
> > 
> > >From a livepatch code standpoint, let's avoid adding complexity (or
> > limitations) where none are needed.  I think all we need to do is
> > permanently disable patch module unloading when somebody forces a patch,
> > which we already do.  Otherwise the user is on their own.

I agree with Josh here.

If there is a problem with a patch module, the recommended action is to 
simply cancel its transition (by writing 0 to enabled). If there are 
serious reasons to apply the patch, there is force as the last resort. In 
that case the user should probably plan for reboot into an updated kernel 
and not to plan to apply more live patches. 
 
> This looks like a rather weak protection against nuclear diseases ;-)
> 
> If we want to keep it simple and safe, we should either print
> a big fact warning about this danger when the option is used.
> Or we should allow to load new patches only with yet another
> force flag.

Having said the above, I'm not against to update the warning and 
documentation. I would not introduce another force flag to deal with it.

Thanks,
Miroslav

  reply	other threads:[~2017-12-21 13:55 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 [this message]
2017-12-21 14:58   ` Petr Mladek
2017-12-22 13:10     ` Miroslav Benes
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.1712211449330.7824@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).