Skip to content
  • Wang Nan's avatar
    perf bpf: Fix endianness problem when loading parameters in prologue · db26984a
    Wang Nan authored
    Perf's BPF prologue generator unconditionally fetches 8 bytes for
    function parameters, which causes problems on big endian machines. Thomas
    gives a detailed analysis for this problem:
    
     http://lkml.kernel.org/r/968ebda5-abe4-8830-8d69-49f62529d151@linux.vnet.ibm.com
    
    
    
     ---- 8< ----
      I investigated perf test BPF for s390x and have a question regarding
      the 38.3 subtest (bpf-prologue test) which fails on s390x.
    
      When I turn on trace_printk in tests/bpf-script-test-prologue.c
      I see this output in /sys/kernel/debug/tracing/trace:
    
      [root@s8360047 perf]# cat /sys/kernel/debug/tracing/trace
      perf-30229 [000] d..2 170161.535791: : f_mode 2001d00000000 offset:0 orig:0
      perf-30229 [000] d..2 170161.535809: : f_mode 6001f00000000 offset:0 orig:0
      perf-30229 [000] d..2 170161.535815: : f_mode 6001f00000000 offset:1 orig:0
      perf-30229 [000] d..2 170161.535819: : f_mode 2001d00000000 offset:1 orig:0
      perf-30229 [000] d..2 170161.535822: : f_mode 2001d00000000 offset:2 orig:1
      perf-30229 [000] d..2 170161.535825: : f_mode 6001f00000000 offset:2 orig:1
      perf-30229 [000] d..2 170161.535828: : f_mode 6001f00000000 offset:3 orig:1
      perf-30229 [000] d..2 170161.535832: : f_mode 2001d00000000 offset:3 orig:1
      perf-30229 [000] d..2 170161.535835: : f_mode 2001d00000000 offset:4 orig:0
      perf-30229 [000] d..2 170161.535841: : f_mode 6001f00000000 offset:4 orig:0
    
      [...]
    
      There are 3 parameters the eBPF program tests/bpf-script-test-prologue.c
      accesses: f_mode (member of struct file at offset 140) offset and orig.  They
      are parameters of the lseek() system call triggered in this test case in
      function llseek_loop().
    
      What is really strange is the value of f_mode. It is an 8 byte value, whereas
      in the probe event it is defined as a 4 byte value.  The lower 4 bytes are all
      zero and do not belong to member f_mode.  The correct value should be 2001d for
      read-only and 6001f for read-write open mode.
    
      Here is the output of the 'perf test -vv bpf' trace:
      Try to find probe point from debuginfo.
      Matched function: null_lseek [2d9310d]
       Probe point found: null_lseek+0
      Searching 'file' variable in context.
      Converting variable file into trace event.
      converting f_mode in file
      f_mode type is unsigned int.
      Opening /sys/kernel/debug/tracing//README write=0
      Searching 'offset' variable in context.
      Converting variable offset into trace event.
      offset type is long long int.
      Searching 'orig' variable in context.
      Converting variable orig into trace event.
      orig type is int.
      Found 1 probe_trace_events.
      Opening /sys/kernel/debug/tracing//kprobe_events write=1
      Writing event: p:perf_bpf_probe/func _text+8794224 f_mode=+140(%r2):x32
     ---- 8< ----
    
    This patch parses the type of each argument and converts data from memory to
    expected type.
    
    Now the test runs successfully on 4.13.0-rc5:
    
      [root@s8360046 perf]# ./perf test  bpf
      38: BPF filter                                 :
      38.1: Basic BPF filtering                      : Ok
      38.2: BPF pinning                              : Ok
      38.3: BPF prologue generation                  : Ok
      38.4: BPF relocation checker                   : Ok
      [root@s8360046 perf]#
    
    Signed-off-by: default avatarWang Nan <wangnan0@huawei.com>
    Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/20170815092159.31912-1-tmricht@linux.vnet.ibm.com
    
    
    Signed-off-by: default avatarThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
    Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
    db26984a