ftrace: handle kernel code remove
Status from this message: applied to tip/tracing/ftrace - thanks Steve! I merged it into
Get series with b4
b4 am [email protected]Versions newest first
Patches in v1 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | ftrace: do not show freed records in available_filter_functionskernel/ | +4 | 0 replies | |
| 2/3 | ftrace: move notrace to compiler.hinclude/ include/ | +2 | 0 replies | |
| 3/3 | ftrace: remove old pointers to mcountinclude/ include/ kernel/ +1 more | +41 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] ftrace: handle kernel code remove
The dynamic ftrace feature keeps a table of all the places that call mcount to either disable them (replacing them with nops) or to enable them (calling some trace function).
This table of functions is also displayed to the user interface to let users enable or disable specific functions. This allows users to only trace some functions within the kernel.
When a module or init sections are removed, the pointers to their locations still exist in this table. To protect against faults and writing over other text, fault handling and code comparing is done. When the code is update, the code being replaced is calculated and compared to the actual text that is being replaced, if the code does not match what is expected to be there, the change is not made.
There is a very small chance that the wrong text (or perhaps a data section) could match the call to mcount and an inappropriate modification could be made.
This patch series adds ftrace_release, to allow a module to remove the pointers to the mcount callers in the module from this table.
Also, __init has "notrace" added to it so that text in the init section are not traced. The trace currently can not be enabled until after init anyway, so this should not be a problem.
-- Steve