Messages in this thread | | | From | Song Liu <> | Subject | Re: [RFC] sched,livepatch: call stop_one_cpu in klp_check_and_switch_task | Date | Tue, 10 May 2022 00:32:02 +0000 |
| |
> 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.
| |