Re: [RFC PATCH 0/9] livepatch: consistency model

Jiri Kosina
2015-02-09T23:15:25Z

On Mon, 9 Feb 2015, Josh Poimboeuf wrote:

> This patch set implements a livepatch consistency model, targeted for 3.21.
> Now that we have a solid livepatch code base, this is the biggest remaining
> missing piece.

Hi Josh,

first, thanks a lot for putting this together. From a cursory look it
certainly seems to be a very solid base for future steps.

I am afraid I won't get to proper review before merge window concludes
though. But after that it gets moved the top of my TODO list.

> This code stems from the design proposal made by Vojtech [1] in November. It
> makes live patching safer in general. Specifically, it allows you to apply
> patches which change function prototypes. It also lays the groundwork for
> future code changes which will enable data and data semantic changes.
>
> It's basically a hybrid of kpatch and kGraft, combining kpatch's backtrace
> checking with kGraft's per-task consistency. When patching, tasks are
> carefully transitioned from the old universe to the new universe. A task can
> only be switched to the new universe if it's not using a function that is to be
> patched or unpatched. After all tasks have moved to the new universe, the
> patching process is complete.
>
> How it transitions various tasks to the new universe:
>
> - The stacks of all sleeping tasks are checked. Each task that is not sleeping
> on a to-be-patched function is switched.
>
> - Other user tasks are handled by do_notify_resume() (see patch 9/9). If a
> task is I/O bound, it switches universes when returning from a system call.
> If it's CPU bound, it switches when returning from an interrupt.

Just one rather minor comment to this -- we can actually switch CPU-bound
processess "immediately" when we notice they are running in userspace
(assuming that we are also migrating them when they are entering the
kernel as well ... which doesn't seem to be implemented by this patchset,
but that could be easily added at low cost).

Relying on IRQs is problematic, because you can have CPU completely
isolated from both scheduler and IRQs (that's what realtime folks are
doing routinely), so you don't see IRQ on that particular CPU for ages.

The way how do detect whether given CPU is running in userspace (without
interfering with it too much, like, say, sending costly IPI) is rather
tricky though. On kernels with CONFIG_CONTEXT_TRACKING we could make use
of that feature, but my gut feeling is that most people keep that
disabled.

Another alternative is what we are doing in kgraft with
kgr_needs_lazy_migration(), but admittedly that's very far from being
pretty.

--
Jiri Kosina
SUSE Labs