[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9FA1822F-76EE-4174-86DD-B20F1F8CE7FC@fb.com>
Date: Mon, 9 May 2022 08:06:22 +0000
From: Song Liu <songliubraving@...com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Song Liu <song@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"live-patching@...r.kernel.org" <live-patching@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"joe.lawrence@...hat.com" <joe.lawrence@...hat.com>,
Kernel Team <Kernel-team@...com>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched
> On May 9, 2022, at 12:04 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Sat, May 07, 2022 at 10:46:28AM -0700, Song Liu wrote:
>> Busy kernel threads may block the transition of livepatch. Call
>> klp_try_switch_task from __cond_resched to make the transition easier.
>
> What will a PREEMPT=y kernel do? How is it not a problem there, and if
> it is, this will not help that.
>
> That is; I don't think this can be right.
I guess on PREEMPT=y kernel, we can simply preempt the long running
kernel thread and check the transition?
In this case (PREEMPT=n), we see a long running kernel thread could not
finish the transition. It calls cond_resched() and gets rescheduled
(moves among different cores). However, it never finishes the transition,
because live patch doesn’t get a chance to check the stack.
Does this answer the question?
Thanks,
Song
Powered by blists - more mailing lists