[Bug tapsets/23160] 4.17 breaks syscalls tapset

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23160

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
As a curiosity, I have a little prototype hacky solution to this problem.

It involves:
- hooking into the __$ARCH_sys_$SYSCALL function (__x64_sys_read etc.)
- grabbing its $regs (pt_regs*) parameter
- reusing the nd_$SYSCALL probe alias parameter handling (int_arg(2) etc.)

... but how?  Add this to some common .stp file:

function set_user_mode(r) %{
    c->uregs = (void*)STAP_ARG_r;
    c->user_mode_p = 1;
    %}

... and a variant of this to every sysc_*.stp file:

probe __nd_syscall.read = kernel.function("__x64_sys_read")
{
  set_user_mode($regs)
}

Then the preexisting nd_syscall.read alias works unmodified:

probe nd_syscall.read =
        __nd_syscall.read
{
        @_SYSCALL_READ_NAME
        asmlinkage()
        fd = int_arg(1)
        buf_uaddr = pointer_arg(2)
[...]
}

i.e., the set_user_mode function tricks probes built upon this alias
into thinking that the pt_regs* given to the new syscall wrapper is the
new proper register set for later registers.stp function calls to read
from.

(Season to taste; adjust kernel.function -> kprobe.function() and int_arg(2)
to fetch $regs probably.)

One big downside: no access to individual parameters as context variables.
I guess we missed that with nd_syscall probes already.  But that means that
it's not possible to modify the parameters in the stap probe before they
get relayed to the real __do_sys_FUNCTION.

-- 
You are receiving this mail because:
You are the assignee for the bug.