lkml.org 
[lkml]   [2022]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] sched,livepatch: call stop_one_cpu in klp_check_and_switch_task
Date


> On May 9, 2022, at 1:09 PM, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Mon, May 09, 2022 at 03:49:52PM -0400, Rik van Riel wrote:
>> On Mon, 2022-05-09 at 12:17 -0700, Josh Poimboeuf wrote:
>>> On Mon, May 09, 2022 at 03:10:16PM -0400, Rik van Riel wrote:
>>>
>>>
>>>> Should kernel threads that can use a lot of CPU have
>>>> something in their outer loop to transition KLPs,
>>>> just like the idle task does?
>>>
>>> Maybe - I suppose this is the first time we've had an issue with
>>> CPU-bound kthreads. I didn't know that was a thing ;-)
>>>
>> Kworkers have as much work as you want them to do, and with
>> things like btrfs compression that can be quite a bit.
>
> To prevent patching, it would need to be some kind of sustained CPU
> activity, rather than a burst. I guess we haven't seen that show up as
> a real-world problem until now.

Yes, we see this issue with sustained CPU activity from a kernel
thread, which might be a bug itself. OTOH, the kernel thread does
call cond_sched(), so it is not a deadlock.

>
> If you're able to identify which kthreads would be problematic, then
> yeah, defining a "transition point" in their outer loops could be an
> option.

cond_sched() feels like a natural “transition point” to me, and it
should solve many different variations of such problem. I agree that
adding something to cond_sched() might be too much overhead for the
system. So we are open for other suggestions.

Thanks,
Song

>
> We could look also at a more general approach, like stack checking from
> an irq handler. But as Petr alluded to, that would be problematic for
> CONFIG_FRAME_POINTER.
>
> We could maybe deprecate frame pointers on x86 for live patching, but I
> think other arches would have a similar problem unless they were to do
> something like the ORC unwinder.

\
 
 \ /
  Last update: 2022-05-10 02:32    [W:0.136 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site