On Fri, Nov 14, 2014 at 09:58:19PM +0100, Vojtech Pavlik wrote: > > > and any proces executing syscalls can be migrated when on the > > > kernel/userspace boundary. And processes that are sleeping are already > > > handled. > > > > Yes, but now you're getting into LEAVE_KERNEL territory. And we'd have > > to modify syscall > > Yes. > > > and kthread code again... > > No. > > Unlike userspace processes, there are no kthreads that are cpu-bound for > extended time periods. If there would be, that's a bug. They all go to > sleep eventually. Hm, how do you migrate unfreezable kthreads which are sleeping on the patched function without modifying the kthread code? The only other options I can think of are: - return an error - install an ftrace handler on the patched function which checks the stack and migrates if possible - install a kprobe handler at the exit of the function (perhaps at the instruction after the parent call ip) which checks the stack and migrates if possible > > But... maybe let's forget all that. Here's yet another idea which is > > currently my favorite :-) > > > > 1. Install an ftrace handler at the beginning of every to-be-patched > > function which converts the current thread to the new universe if > > there are no other patched functions on its stack. > > > > 2. Run the following on each cpu (smp_call_function): > > for each thread > > if task_cpu(task) == this cpu > > check backtrace and convert thread to new universe if possible > > > > [ This introduces some scheduling latency, but it's much better than > > stop_machine. ] > > I don't see how you can guarantee that this sleeping task will not > be woken up on another CPU while you're checking, given that > smp_call_function isn't synchronous on all CPUs. I think the task->pi_lock may accomplish that, but I need to do more investigation. If necessary we could also track which threads have been checked in order to catch any that changed CPUs while were checking and slipped through the cracks. > > 3. Send fake signals to any remaining old universe tasks, and wait for > > the ftrace handler to convert them. > > A fake signal (like in freezer) only works on threads in userspace to > bring them into the kernel. It won't wake them up from sleeping loops > waiting for some event. Ah, this does seem to be true in some cases, like when freezable_schedule() is called. Freezing is less predictable than I thought, which makes this option less attractive. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
