live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Cc: live-patching@vger.kernel.org, pmladek@suse.com, nstange@suse.de
Subject: Re: Patching kthread functions
Date: Fri, 2 Oct 2020 15:06:11 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.21.2010021501510.24950@pobox.suse.cz> (raw)
In-Reply-To: <1cdecdce-fb34-29aa-1dda-1d02d8a635ef@virtuozzo.com>

On Fri, 2 Oct 2020, Evgenii Shatokhin wrote:

> On 02.10.2020 14:53, Miroslav Benes wrote:
> > 
> >>>> The old function will continue running, right?
> >>>
> >>> Correct. It will, however, call new functions.
> >>
> >> Ah, I see.
> >>
> >> So, I guess, our best bet would be to rewrite the thread function so that
> >> it
> >> contains just the event loop and calls other non-inline functions to
> >> actually
> >> process the requests. And, perhaps, - place klp_update_patch_state() before
> >> schedule().
> > 
> > Yes, that might be the way. klp_update_patch_state() might not be even
> > needed. If the callees are live patched, the kthread would be migrated
> > thanks to stack checking once a task leaves the callee.
> 
> You mean, the task runs the callee, then goes to schedule(), then, while it
> waits, livepatch core checks its stack, sees no target functions there and
> switches patch_state?

Yes. Once the task gets out of the target function (or the set of 
functions), its patch state can be changed. If it sleeps (interruptedly) 
in the target function, we wake it up so it can get out 
(klp_send_signals()).
 
> >   
> >> This will not help with this particular kernel version but could make it
> >> possible to live-patch the request-processing functions in the future
> >> kernel
> >> versions. The main thread function will remain unpatchable but it will call
> >> the patched functions once we switch the patch_state for the thread.
> > 
> > Yes. The only issue is if the intended fix changes the semantics which is
> > incompatible between old and new functions (livepatch consistency model is
> > LEAVE_PATCHED_SET, SWITCH_THREAD, see
> > https://lore.kernel.org/lkml/20141107140458.GA21774@suse.cz/ for the
> > explanation if interested).
> 
> Yes, I have read that.
> 
> In our case, the fix only adds a kind of lock/unlock around the part of the
> function processing actual requests. The implementation is more complex, but,
> essentially, it is lock + unlock. The code not touched by the patch already
> handles such locking OK, so it can work both with old and the new versions of
> patched functions. And - even if some threads use the old functions and some -
> the new ones. So, I guess, it should be fine.

Ok, that should be fine.

Miroslav

  reply	other threads:[~2020-10-02 13:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 15:44 Patching kthread functions Evgenii Shatokhin
2020-10-01 11:13 ` Miroslav Benes
2020-10-01 12:43   ` Nicolai Stange
2020-10-01 13:18     ` Evgenii Shatokhin
2020-10-01 13:12   ` Evgenii Shatokhin
2020-10-02 11:53     ` Miroslav Benes
2020-10-02 12:52       ` Evgenii Shatokhin
2020-10-02 13:06         ` Miroslav Benes [this message]
2020-10-01 14:46   ` Petr Mladek
2020-10-01 16:34     ` Evgenii Shatokhin

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.2010021501510.24950@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=eshatokhin@virtuozzo.com \
    --cc=live-patching@vger.kernel.org \
    --cc=nstange@suse.de \
    --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).