live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: JeffleXu <jefflexu@linux.alibaba.com>
Cc: jpoimboe@redhat.com, live-patching@vger.kernel.org
Subject: Re: [help] Confusion on livepatch's per-task consistency model
Date: Mon, 2 Mar 2020 11:12:07 +0100	[thread overview]
Message-ID: <20200302101207.57i4opglpgaynfju@pathway.suse.cz> (raw)
In-Reply-To: <315f87a7-eb40-67a7-4ab9-4b384fde752a@linux.alibaba.com>

On Mon 2020-03-02 16:45:24, JeffleXu wrote:
> Hello guys,
> 
> 
> I'm new to livepatch world and now I'm a little confused with livepatch's
> 
> per-task consistency model which is introduced by [1]. I've also readed the
> 
> discussion on mailing list [2], which introduces shadow variable to handle
> 
> data layout and semantic changes. But there's still some confusion with this
> 
> per-task consistency model.
> 
> 
> According to the model, there will be scenario where old function and new
> 
> function can co-exist, though for a single thread, it sees either all new
> 
> functions or all old functions.
> 
> 
> I can't understand why Vojtech said that 'old func processing new data' was
> 
> impossible. Assuming a scenario where a process calls func-A to submit a
> 
> work request (inserted into a global list), and then a kthread is
> responsible
> 
> for calling func-B to process all work requests in the list. What if this
> process
> 
> has finished the transition (sees new func-A) while kthread still sees the
> old func-B?
> 
> In this case, old func-B has to process new data. If there's some lock
> semantic
> 
> changes in func-A and func-B, then old func-B has no way identifying the
> shadow
> 
> variable labeled by new func-A.
> 
> 
> Please tell me if I missed something, and any suggestions will be
> appreciated. ;)

No, you did not miss anything. The consistency is only per-thread,
If a livepatch is changing semantic of a global variable it must
allow doing the changes only when the entire system is using
the new code. And the new code must be able to deal with both
old and new data.

The new data semantic can be enable by post-patch callback
that is called when the transition has finished.

Fortunately, semantic changes are very rare at least in security
fixes.

Best Regards,
Petr

  reply	other threads:[~2020-03-02 10:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02  8:45 [help] Confusion on livepatch's per-task consistency model JeffleXu
2020-03-02 10:12 ` Petr Mladek [this message]
2020-03-02 12:56   ` JeffleXu
2020-03-02 10:36 ` Nicolai Stange
2020-03-02 13:19   ` JeffleXu
2020-03-02 16:58     ` Nicolai Stange

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=20200302101207.57i4opglpgaynfju@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=jpoimboe@redhat.com \
    --cc=live-patching@vger.kernel.org \
    /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).