[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