Bug 1824812

Summary: Tracepoints: operational test: kernel.trace("iocost:iocost_ioc_vrate_adj") compilation failure
Product: Red Hat Enterprise Linux 8 Reporter: Frantisek Hrbata <fhrbata>
Component: systemtapAssignee: Frank Ch. Eigler <fche>
systemtap sub component: system-version QA Contact: qe-baseos-tools-bugs
Status: CLOSED WONTFIX Docs Contact:
Severity: unspecified    
Priority: unspecified CC: jbastian, lberk, llong, mcermak, minlei, mjw, pbunyan, rasibley
Version: 8.3Keywords: Triaged
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1828563 (view as bug list) Environment:
Last Closed: 2020-05-07 15:36:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frantisek Hrbata 2020-04-16 13:47:48 UTC
Description of problem:

Block layer update bug 1798919 adds iocost_ioc_vrate_adj trace point.
include/trace/events/iocost.h

TRACE_EVENT(iocost_ioc_vrate_adj,
        TP_PROTO(struct ioc *ioc, u64 new_vrate, u32 (*missed_ppm)[2],

It looks like the stap translate does not like the pointer to array as
parameter. I'm not sure if this needs to be fixed on stap side or the trace event should use different interface(maybe just u32 *missed_ppm)


Version-Release number of selected component (if applicable):
rhel8.3 kernel with patches for bug 1798919
Scratch build kernel-4.18.0-193.9.el8.test.cki available here
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=27943933
Note this is a testing build for the upcoming kernel-4.18.0-193.9.el8


How reproducible:
easily

Steps to Reproduce:
1. stap -p4 -k -v  -e 'probe kernel.trace("iocost:iocost_ioc_vrate_adj") { if (pid() == 0) printf("probe hit\n"); }'
2.
3.

Actual results:
Pass 1: parsed user script and 478 library scripts using 238888virt/80668res/11980shr/68204data kb, in 180usr/20sys/197real ms.
Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 242436virt/85156res/12912shr/71752data kb, in 440usr/180sys/621real ms.
Pass 3: translated to C into "/tmp/stapoCIhdW/stap_45624_src.c" using 242436virt/85156res/12912shr/71752data kb, in 0usr/0sys/0real ms.
In file included from /tmp/stapoCIhdW/stap_45624_aux_0.c:8:
/tmp/stapoCIhdW/stap_45624_aux_0.c:15:8: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
 , u32[]* __tracepoint_arg_missed_ppm


/tmp/stapoCIhdW/stap_45624_aux_0.c

include <trace/events/iocost.h>
STP_TRACE_ENTER_REAL_NOARGS(enter_real_tracepoint_probe_0);
static STP_TRACE_ENTER(enter_tracepoint_probe_0
, struct ioc* __tracepoint_arg_ioc
, u64 __tracepoint_arg_new_vrate
, u32[]* __tracepoint_arg_missed_ppm
  ^^^^^
  vs u32 (*)[2] / u32 (*__tracepoint_arg_missed_ppm)[2]
, u32 __tracepoint_arg_rq_wait_pct
, int __tracepoint_arg_nr_lagging
, int __tracepoint_arg_nr_shortages
, int __tracepoint_arg_nr_surpluses
)
{
  enter_real_tracepoint_probe_0(
      );
}


Expected results:
module for iocost_ioc_vrate_adj can be compiled and used

Additional info:

Comment 1 Ming Lei 2020-04-17 07:52:39 UTC
Hello,

I'd suggest to fix stap since not see similar issue in bcc or ebpf based trace tools.

And our policy is to align with upstream, and it may not be reasonble to ask upstream
to change this traceevent code.

Also we will have same issue in rhel9.

thanks,
Ming

Comment 2 Frank Ch. Eigler 2020-04-20 20:54:09 UTC
*** Bug 1825951 has been marked as a duplicate of this bug. ***

Comment 3 Waiman Long 2020-04-21 19:08:55 UTC
I have posted an upstream kernel patch to change the parameter type of missed_ppm to "u32 *" as the original one is really hard to read:

https://lore.kernel.org/lkml/20200421185800.22094-1-longman@redhat.com/

The systemtap folks can of course continue to address this issue to make sure that it can parse C parameter types correctly.

Cheers,
Longman

Comment 5 Frank Ch. Eigler 2020-05-07 15:36:37 UTC
Thanks to the kernel folks' changes, systemtap doesn't have to learn to handle that syntax for now.

Comment 6 RHEL Program Management 2020-05-07 15:36:43 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.