[Bug translator/29028] New: Linux 5.18.0 kernels changed struct kretprobe_instance member fields and scripts with return probes fail to compile

[Bug translator/29028] New: Linux 5.18.0 kernels changed struct kretprobe_instance member fields and scripts with return probes fail to compile

[wcohen at redhat dot com]

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

            Bug ID: 29028
           Summary: Linux 5.18.0 kernels changed struct kretprobe_instance
                    member fields and scripts with return probes fail to
                    compile
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

The following kernel commit 73f9b911faa74ac5107879de05c9489c419f41bb in the
linux 5.18.0-rc kernel changed the struct kretprobe_instance members which
causes scripts with return kernel probes fail to build:

    kprobes: Use rethook for kretprobe if possible

    Use rethook for kretprobe function return hooking if the arch sets
    CONFIG_HAVE_RETHOOK=y. In this case, CONFIG_KRETPROBE_ON_RETHOOK is
    set to 'y' automatically, and the kretprobe internal data fields
    switches to use rethook. If not, it continues to use kretprobe
    specific function return hooks.

    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link:
https://lore.kernel.org/bpf/164826162556.2455864.12255833167233452047.stgit@devnote2

On Fedora 37 (rawhide) running
kernel-5.18.0-0.rc0.20220401gite8b767f5e04097a.15.fc37.x86_64 and locally built
systemtap from git checkout can replicate the issue with:

$ sudo ../install/bin/stap --example alias_suffixes.stp -T 1
In file included from
/home/wcohen/systemtap_write/install/share/systemtap/runtime/linux/../regs.c:16,
                 from
/home/wcohen/systemtap_write/install/share/systemtap/runtime/linux/runtime.h:270,
                 from
/home/wcohen/systemtap_write/install/share/systemtap/runtime/runtime.h:26,
                 from
/tmp/stapIaZ5Mo/stap_90ca7a4095946c1447d5febbb2252e46_85937_src.c:21:
/tmp/stapIaZ5Mo/stap_90ca7a4095946c1447d5febbb2252e46_85937_src.c: In function
‘enter_kretprobe_common’:
/tmp/stapIaZ5Mo/stap_90ca7a4095946c1447d5febbb2252e46_85937_src.c:6484:45:
error: ‘struct kretprobe_instance’ has no member named ‘ret_addr’
 6484 |         SET_REG_IP(regs, (unsigned long)inst->ret_addr);
      |                                             ^~
/home/wcohen/systemtap_write/install/share/systemtap/runtime/linux/../regs.h:85:44:
note: in definition of macro ‘SET_REG_IP’
   85 | #define SET_REG_IP(regs, x) REG_IP(regs) = x
      |                                            ^
make[1]: *** [scripts/Makefile.build:288:
/tmp/stapIaZ5Mo/stap_90ca7a4095946c1447d5febbb2252e46_85937_src.o] Error 1
make: *** [Makefile:1848: /tmp/stapIaZ5Mo] Error 2
WARNING: kbuild exited with status: 2
Pass 4: compilation failed.  [man error::pass4]


There are a number of places in tapsets.cxx directly referencing ret_addr field
which is removed from struct kretprobe_instance.  Looking at how the kernel
handles this there is small inlined helper function to "do the right thing",
get_kretprobe_retaddr
(https://elixir.bootlin.com/linux/v5.18-rc1/C/ident/get_kretprobe_retaddr). 
Looks like systemtap should have a similar __stp_* function to do the same.

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

[Bug translator/29028] Linux 5.18.0 kernels changed struct kretprobe_instance member fields and scripts with return probes fail to compile

[wcohen at redhat dot com]

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

--- Comment #1 from William Cohen <wcohen at redhat dot com> ---
Created attachment 14080
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14080&action=edit
Provide a helper function to get ret_addr from the correct struct

The ret_addr field moves between structs based on CONFIG_KRETPROBE_ON_RETHOOK. 
Only observed this on x86_64 rawhide 5.18.0* kernels so far.  The kernel change
just appears to affect the kretprobes and not the uprobes.  This patch allows
the reproducer to work on fedora rawhide.  Now testing it on x86_64 f35 and
other places to verify that it doesn't break things.

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

[Bug translator/29028] Linux 5.18.0 kernels changed struct kretprobe_instance member fields and scripts with return probes fail to compile

[wcohen at redhat dot com]

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

William Cohen <wcohen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14080|0                           |1
        is obsolete|                            |

--- Comment #2 from William Cohen <wcohen at redhat dot com> ---
Created attachment 14081
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14081&action=edit
v2 of the patch

Found that runtime/linux/regs.c had a macro to access to ret_addr field so
updated the macro to do the right thing when CONFIG_KRETPROBE_ON_RETHOOK is set
and just have the tapsets.cxx generated code also uses that macro.

Running the systemtap.examples/check.exp tests on 86_64 rawhide and f35 to see
that the patch doesn't cause any regressions.

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

[Bug translator/29028] Linux 5.18.0 kernels changed struct kretprobe_instance member fields and scripts with return probes fail to compile

[wcohen at redhat dot com]

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

William Cohen <wcohen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
This has been fixed by commit 508d8f91dfa95ca9ca939c90e12bda446330e955

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