All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Miroslav Benes <mbenes@suse.cz>, Jiri Kosina <jikos@kernel.org>,
	Jessica Yu <jeyu@redhat.com>,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org
Subject: Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model
Date: Tue, 5 Apr 2016 13:36:34 +0200	[thread overview]
Message-ID: <20160405113634.GA5930@suse.cz> (raw)
In-Reply-To: <20160404183307.2hbht3g4l7ei54rt@treble.redhat.com>

On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> > 
> > > Hm, can you explain why it should be copied from the parent?
> > > 
> > > I'm thinking the above code is correct for today, but it should still be
> > > changed to be more future-proof.
> > > 
> > > Here's my thinking:
> > > 
> > > A forked task starts out with no stack, so if I understand correctly, it
> > > can safely start out in the goal universe, regardless of which universe
> > > its parent belongs to.
> > > 
> > > However, the current ret_from_fork code is a mess, and Andy Lutomirski
> > > has mentioned that he would like to give newly forked tasks a proper
> > > stack such that instead of jumping to ret_from_fork, they would just
> > > return from schedule().  In that case, it would no longer be safe to
> > > start the new task in the goal universe because it could be "sleeping"
> > > on a to-be-patched function.
> > > 
> > > So for proper future proofing, newly forked tasks should be started in
> > > the initial universe (rather than starting in the goal universe or
> > > inheriting the parent's universe).  They can then be transitioned over
> > > to the goal universe like any other task.  How does that sound?
> > 
> > How could a newly forked task start in the old universe if its parent
> > has already been migrated? Any context it inherits will already be from
> > the new universe.
> 
> Can you be more specific about "context" and why inheritance of it would
> be a problem?

Currently a forked task starts out with no stack, and as such it can
start in the goal universe.

If we create a synthetic stack, then we may need to start in the initial
universe, as the synthetic stack would likely be created using initial
universe return addresses. 

If we simply copy the stack of the parent process, which is in my
opionion the safest way, as it places little assumptions on the
compiler, then it may contain either old or new addresses
and we need to copy the universe flag along.

-- 
Vojtech Pavlik
Director SUSE Labs

  reply	other threads:[~2016-04-05 11:36 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25 19:34 [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 01/14] x86/asm/head: cleanup initial stack variable Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 02/14] x86/asm/head: use a common function for starting CPUs Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 03/14] x86/asm/head: standardize the bottom of the stack for idle tasks Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 04/14] x86: move _stext marker before head code Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 05/14] sched: horrible way to detect whether a task has been preempted Josh Poimboeuf
2016-04-06 13:06   ` Petr Mladek
2016-04-06 16:33     ` Josh Poimboeuf
2016-04-07  9:47       ` Petr Mladek
2016-04-07 14:34         ` Josh Poimboeuf
2016-04-08  8:07           ` Petr Mladek
2016-04-08 14:34             ` Josh Poimboeuf
2016-04-07 21:15   ` Jessica Yu
2016-04-07 21:37     ` Jiri Kosina
2016-04-07 22:35       ` Josh Poimboeuf
2016-04-07 22:53         ` Jiri Kosina
2016-04-07 23:15       ` Jessica Yu
2016-04-08  7:05         ` Jiri Kosina
2016-04-08  8:03           ` Petr Mladek
2016-04-08 14:31             ` Josh Poimboeuf
2016-04-11  8:38               ` Petr Mladek
2016-03-25 19:34 ` [RFC PATCH v1.9 06/14] x86: add error handling to dump_trace() Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces Josh Poimboeuf
2016-03-31 13:03   ` Miroslav Benes
2016-04-04 17:54     ` Josh Poimboeuf
2016-04-11 14:16       ` Jiri Slaby
2016-04-12 15:56         ` Josh Poimboeuf
2016-06-09  8:31           ` Jiri Slaby
2016-06-13 21:58             ` Josh Poimboeuf
2016-12-01 20:28               ` Jiri Slaby
2016-12-01 20:59                 ` Josh Poimboeuf
2017-01-17 13:08                   ` Jiri Slaby
2016-04-04 15:55   ` Petr Mladek
2016-04-04 17:58     ` Josh Poimboeuf
2016-04-07 11:55   ` Petr Mladek
2016-04-07 14:46     ` Josh Poimboeuf
2016-04-08  8:24       ` Petr Mladek
2016-04-11  3:29   ` Jessica Yu
2016-03-25 19:34 ` [RFC PATCH v1.9 08/14] livepatch: separate enabled and patched states Josh Poimboeuf
2016-04-11  3:31   ` Jessica Yu
2016-04-12 14:44   ` [RFC PATCH v1.9 08/14] " Chris J Arges
2016-04-12 17:16     ` Josh Poimboeuf
2016-04-12 17:35       ` Chris J Arges
2016-04-12 18:25         ` Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 09/14] livepatch: remove unnecessary object loaded check Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 10/14] livepatch: move patching functions into patch.c Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 11/14] livepatch: store function sizes Josh Poimboeuf
2016-03-25 19:34 ` [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model Josh Poimboeuf
2016-03-31 13:12   ` Miroslav Benes
2016-04-04 18:21     ` Josh Poimboeuf
2016-04-04 18:27       ` Vojtech Pavlik
2016-04-04 18:33         ` Josh Poimboeuf
2016-04-05 11:36           ` Vojtech Pavlik [this message]
2016-04-05 13:53             ` Josh Poimboeuf
2016-04-05 17:32   ` Minfei Huang
2016-04-05 21:17     ` Josh Poimboeuf
2016-04-14  9:25   ` Miroslav Benes
2016-04-14 16:39     ` Josh Poimboeuf
2016-04-15  9:17       ` Miroslav Benes
2016-03-25 19:35 ` [RFC PATCH v1.9 13/14] livepatch: add /proc/<pid>/patch_status Josh Poimboeuf
2016-03-31  9:33   ` Jiri Slaby
2016-03-31  9:40     ` Jiri Slaby
2016-04-04 16:56     ` Josh Poimboeuf
2016-03-25 19:35 ` [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel Josh Poimboeuf
2016-04-14  8:47   ` Miroslav Benes
2016-04-14  8:50     ` Miroslav Benes
2016-04-14 13:39       ` Josh Poimboeuf
2016-04-18 15:01         ` [RFC PATCH 0/2] s390/klp: s390 support Miroslav Benes
2016-04-18 15:01           ` [RFC PATCH 1/2] s390: livepatch, reorganize TIF bits Miroslav Benes
2016-04-18 15:01           ` [RFC PATCH 2/2] s390/klp: update task universe when exiting kernel Miroslav Benes
2016-04-18 15:17           ` [RFC PATCH 0/2] s390/klp: s390 support Josh Poimboeuf
2016-04-14 13:23     ` [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel Josh Poimboeuf
2016-03-31 12:54 ` [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Miroslav Benes
2016-04-04 17:03   ` Josh Poimboeuf
2016-04-05 14:24     ` Miroslav Benes
2016-04-05 14:34       ` Josh Poimboeuf
2016-04-05 14:53         ` Miroslav Benes
2016-04-01 13:34 ` Miroslav Benes
2016-04-01 13:39 ` Petr Mladek
2016-04-01 15:38   ` Petr Mladek
2016-04-05 13:44   ` Josh Poimboeuf
2016-04-06  8:15     ` Petr Mladek
2016-04-28 18:53     ` Josh Poimboeuf
2016-06-09 14:20       ` Petr Mladek
2016-04-07 12:10 ` Petr Mladek
2016-04-07 15:08   ` Josh Poimboeuf
2016-04-07 15:47     ` Jiri Kosina
2016-04-07 18:03       ` Josh Poimboeuf
2016-04-07 18:33         ` Jiri Kosina

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=20160405113634.GA5930@suse.cz \
    --to=vojtech@suse.com \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@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.