All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>, Petr Mladek <pmladek@suse.com>,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] livepatch: Enforce reliable stack trace as config dependency
Date: Tue, 16 Apr 2019 20:52:12 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.21.1904162047180.9731@pobox.suse.cz> (raw)
In-Reply-To: <20190416125446.hh2dpzwgixnkubwr@treble>

On Tue, 16 Apr 2019, Josh Poimboeuf wrote:

> On Tue, Apr 16, 2019 at 01:47:30PM +0200, Jiri Kosina wrote:
> > On Tue, 12 Feb 2019, Petr Mladek wrote:
> > 
> > > > I think I'd rather go in the opposite direction: allow the patches to be
> > > > loaded.  Then they can be forced, if needed.  That enables both compile
> > > > and runtime testing.  That way we don't make any backward progress,
> > > > until such arches get reliable stacktraces.
> > > 
> > > Do you mean to convert the error into warning?
> > > 
> > > For example, the change below. Note that I did not mention
> > > the possibility to force the transition by intention. It is risky
> > > and people should not get used to it.
> > > 
> > > Heh, I think that this was the main reason why it was the error.
> > > We did not want to get people used to forcing livepatches.
> > > 
> > > 
> > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > > index d1af69e9f0e3..8d9bce251516 100644
> > > --- a/kernel/livepatch/core.c
> > > +++ b/kernel/livepatch/core.c
> > > @@ -1035,11 +1035,10 @@ int klp_enable_patch(struct klp_patch *patch)
> > >  		return -ENODEV;
> > >  
> > >  	if (!klp_have_reliable_stack()) {
> > > -		pr_err("This architecture doesn't have support for the livepatch consistency model.\n");
> > > -		return -EOPNOTSUPP;
> > > +		pr_warn("This architecture doesn't have support for the livepatch consistency model.\n");
> > > +		pr_warn("Only one livepatch can be installed.\n");
> > >  	}
> > >  
> > > -
> > 
> > This seems to have been lost.
> 
> Sorry, this must have gotten lost in my inbox - yes, something like the
> above is what I had in mind.  Though instead of "one livepatch can be
> installed" it might say that the patch transition may never complete.

Sounds better to me too.
 
> BTW, might we want to consider adding a way to say "this patch doesn't
> need the consistency model", which just applies the patch immediately
> like we used to?  Like patch->simple = true?  Then we could easily
> support all arches for basic patches.

I'd rather not return to immediate. There was a bug (commit d0807da78e11 
("livepatch: Remove immediate feature") explains it), it made the code 
complicated and it was impossible to disable patches/remove modules with 
that. After all, the consistency model gives us not only the consistency, 
but also assurance that all tasks were migrated outside of patched 
functions.

> > I think we should take this aproach before Miroslav is ready with 
> > realiable stack traces for s390. At the same time, I'd suggest issuing a 
> > proper WARN() there instead of just pr_warn(). The kernel might be in a 
> > potentially funky state, so let's at least get the 'W' taint in place.
> 
> I don't think it would be in a dangerous state, because
> save_stack_trace_tsk_reliable() will return -ENOSYS and the patch will
> remain in transition forever because the signaling doesn't work for
> kthreads.  So I don't think a warning is necessary.  In fact we may want
> to remove the warning in the generic version of
> save_stack_trace_tsk_reliable().

I would not mind.

Miroslav

      reply	other threads:[~2019-04-16 18:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09  9:17 [PATCH] livepatch: Enforce reliable stack trace as config dependency Kamalesh Babulal
2019-02-11  8:53 ` Petr Mladek
2019-02-11 14:08 ` Josh Poimboeuf
2019-02-12  6:41   ` Kamalesh Babulal
2019-02-12  9:46   ` Petr Mladek
2019-04-16 11:47     ` Jiri Kosina
2019-04-16 12:54       ` Jiri Kosina
2019-04-16 12:55       ` Josh Poimboeuf
2019-04-16 18:52         ` Miroslav Benes [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=alpine.LSU.2.21.1904162047180.9731@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=kamalesh@linux.vnet.ibm.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 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.