On Mon, May 09, 2022 at 03:10:16PM -0400, Rik van Riel wrote:
> On Mon, 2022-05-09 at 11:00 -0700, Josh Poimboeuf wrote:
> > On Mon, May 09, 2022 at 11:52:27AM -0400, Rik van Riel wrote:
> > > Does this look like an approach that could work?
> > >
> > > @@ -315,6 +321,9 @@ static bool klp_try_switch_task(struct
> > > task_struct *task)
> > > case -EBUSY: /* klp_check_and_switch_task() */
> > > pr_debug("%s: %s:%d is running\n",
> > > __func__, task->comm, task->pid);
> > > + /* Preempt the task from the second KLP switch
> > > attempt. */
> > > + if (klp_signals_cnt)
> > > + stop_one_cpu(task_cpu(task),
> > > kpatch_dummy_fn, NULL);
> >
> > I must be missing something, how is briefly preempting a kthread
> > supposed to actually transition it? Won't it likely go back to
> > running
> > on the CPU before the next periodic klp_transition_work_fn() check?
> >
> That's the kind of feedback I was hoping for ;)
>
> I looked around the code a little bit, and it seems
> that only the idle tasks can transition to another KLP
> while they are running?
Yes.
> That makes me wonder how the kworker thread that runs
> the klp switching code transitions itself...
See klp_check_and_switch_task(), in addition to checking blocked tasks,
it also checks the current task.
> 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 ;-)
--
Josh
