archive mirror
 help / color / mirror / Atom feed
From: Miroslav Benes <>
To: Evgenii Shatokhin <>
Subject: Re: Patching kthread functions
Date: Thu, 1 Oct 2020 13:13:07 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 30 Sep 2020, Evgenii Shatokhin wrote:

> Hi,
> I wonder, can livepatch from the current mainline kernel patch the main
> functions of kthreads, which are running or sleeping constantly? Are there any
> best practices here?

No. It is a "known" limitation, "" because we discussed it a couple of 
times (at least with Petr), but it is not documented :(

I wonder if it is really an issue practically. I haven't met a case 
yet when we wanted to patch such thing. But yes, you're correct, it is not 
> I mean, suppose we have a function which runs in a kthread (passed to
> kthread_create()) and is organized like this:
> while (!kthread_should_stop()) {
>   ...
>   DEFINE_WAIT(_wait);
>   for (;;) {
>     prepare_to_wait(waitq, &_wait, TASK_INTERRUPTIBLE);
>     if (we_have_requests_to_process || kthread_should_stop())
>       break;
>     schedule();
>   }
>   finish_wait(waitq, &_wait);
>   ...
>   if (we_have_requests_to_process)
>     process_one_request();
>   ...
> }
> (The question appeared when I was looking at the following code:
> The kthread is always running and never exits the kernel.
> I could rewrite the function to add klp_update_patch_state() somewhere, but
> would it help?

In fact, we used exactly this approach in, now obsolete, kGraft. All 
kthreads had to be manually annotated somewhere safe, where safe meant 
that the thread could be switched to a new universe without the problem 
wrt to calling old/new functions in the loop...

> No locks are held right before and after "schedule()", and the thread is not
> processing any requests at that point.

... like this.

> But even if I place
> klp_update_patch_state(), say, just before schedule(), it would just switch
> task->patch_state for that kthread.


> The old function will continue running, right?

Correct. It will, however, call new functions.

> Looks like we can only switch to the patched code of the function at the
> beginning, via Ftrace hook. So, if the function is constantly running or
> sleeping, it seems, it cannot be live-patched.

Yes and no. Normally, a task cannot run indefinitely and if it sleeps, we 
can deal with that (thanks to stack checking or signaling/kicking the 
task), but kthreads' main loops are special.

> Is that so? Are there any workarounds?

Petr, do you remember the crazy workarounds we talked about? My head is 
empty now. And I am sure, Nicolai could come up with something.


  reply	other threads:[~2020-10-01 11:13 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 [this message]
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
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).