Re: [PATCH 1/3] sched: add sched_task_call()

From: Ingo Molnar
Date: Fri Feb 20 2015 - 04:50:37 EST

* Jiri Kosina <jkosina@xxxxxxx> wrote:

> Alright, so to sum it up:
> - current stack dumping (even looking at /proc/<pid>/stack) is not
> guaranteed to yield "correct" results in case the task is running at the
> time the stack is being examined

Don't even _think_ about trying to base something as
dangerous as live patching the kernel image on the concept

'We can make all stack backtraces reliably correct all
the time, with no false positives, with no false
negatives, 100% of the time, and quickly discover and
fix bugs in that'.

It's not going to happen:

- The correctness of stacktraces partially depends on
tooling and we don't control those.

- More importantly, there's no strong force that ensures
we can rely on stack backtraces: correcting bad stack
traces depends on people hitting those functions and
situations that generate them, seeing a bad stack trace,
noticing that it's weird and correcting whatever code or
tooling quirk causes the stack entry to be incorrect.

Essentially unlike other kernel code which breaks stuff if
it's incorrect, there's no _functional_ dependence on stack
traces, so live patching would be the first (and pretty
much only) thing that breaks on bad stack traces ...

If you think you can make something like dwarf annotations
work reliably to base kernel live patching on that,

Even with frame pointer backtraces can go bad sometimes, I
wouldn't base live patching even on _that_, and that's a
very simple concept with a performance cost that most
distros don't want to pay.

So if your design is based on being able to discover 'live'
functions in the kernel stack dump of all tasks in the
system, I think you need a serious reboot of the whole
approach and get rid of that fragility before any of that
functionality gets upstream!

> - For live patching use-case, the stack has to be
> analyzed (and decision on what to do based on the
> analysis) in the NMI handler itself, otherwise it gets
> racy again

You simply cannot reliably determine from the kernel stack
whether a function is used by a task or not, and actually
modify the kernel image, from a stack backtrace, as things
stand today. Full stop.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at