[kpatch] places where ftrace can be globally disabled
Josh Poimboeuf
jpoimboe at redhat.com
Thu Mar 6 15:47:53 UTC 2014
Steve,
Here are the places I found where ftrace can get globally disabled,
(which would create windows for kpatch patches to become arbitrarily
removed):
1. suspend/hibernate - so I think the long term solution is to make
these functions ftrace-safe. But short term I think you were
suggesting that instead of globally disabling ftrace here, we just
disable ftrace for these functions somehow, right? Can we use
the "notrace" annotation to do that?
2. ftrace_graph_stop - seems to be called in really bad error handling
scenarios. Maybe we could put a panic in there?
3. tracing_open - looks like it stops tracing whenever anybody opens the
global "trace" file for reading. Any ideas about how to get around
this? Perhaps leave tracing enabled but drop all ring buffer writes
instead?
4. ftrace_run_update_code - stops tracing before modifying code. I'm
not sure why this is needed, since the update is done atomically.
5. trace_selftest_startup_* - I'm guessing these are just called during
kernel boot, before a module can be loaded, so they're not really a
problem. Would register_ftrace_function fail if tracing_stop had
been previously called?
--
Josh
More information about the kpatch
mailing list