-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kretprobes / activeness safety incompatibility #67
Comments
More old issue housekeeping ... Still appears to be an issue on 4.19 and 4.20rc5, regardless of the unwinder type. See details below where the ORC unwinder seems more confused than we use frame pointers. @jpoimboe is this last bit reporting to upstream linux-kernel list? Note: the original issue was opened against the kpatch-core activeness safety check, but I think the same problem would apply to in-kernel livepatch tests.zip - kernel patch to add Frame pointer unwinder Base test (no ftrace, no kretprobes)
kretprobe test - no
ftrace graph_function test -
ORC Unwinder Base test (no ftrace, no kretprobes)
kretprobe test - no
ftrace graph_function test -
|
(Btw, github is doing unassignment automatically when I necrobump these issues.) |
@joe-lawrence Thanks a lot for looking at this. I totally forgot about this. It's definitely an upstream issue with both unwinders. They work with function graph tracing because they call ftrace_graph_ret_addr(). When the function graph hook (return_to_handler) is seen on the stack, that function converts it to the real return address. We need something similar for kretprobes. Adding @mhiramat -- Do we have something similar to ftrace_graph_ret_addr() for kretprobes? |
This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added. |
This issue was closed because it was inactive for 7 days after being marked stale. |
This is from an email discussion with @mhiramat.
kretprobes removes the target function's caller from the stack, which means that the kpatch activeness safety check could fail to detect a function on the stack of a process.
I added a dump_stack() call to meminfo_proc_show. Here's the normal
case with no ftrace or kprobes:
Here it is with function_graph tracing enabled. Notice that seq_read is
still on the stack:
And here it is with a kretprobe enabled. Now seq_read is no longer on
the stack, as it has been replaced with kretprobe_trampoline_holder:
Some options:
The text was updated successfully, but these errors were encountered: