1. 31 Jul, 2020 7 commits
    • Ben Hutchings's avatar
      libtraceevent: Fix build with binutils 2.35 · 39efdd94
      Ben Hutchings authored
      In binutils 2.35, 'nm -D' changed to show symbol versions along with
      symbol names, with the usual @@ separator.  When generating
      libtraceevent-dynamic-list we need just the names, so strip off the
      version suffix if present.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Tested-by: default avatarSalvatore Bonaccorso <carnil@debian.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: linux-trace-devel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      39efdd94
    • Wei Li's avatar
      perf tools: Fix record failure when mixed with ARM SPE event · bd3c628f
      Wei Li authored
      When recording with cache-misses and arm_spe_x event, I found that it
      will just fail without showing any error info if i put cache-misses
      after 'arm_spe_x' event.
      
        [root@localhost 0620]# perf record -e cache-misses \
      				-e arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,jitter=1,store_filter=1,min_latency=0/ sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.067 MB perf.data ]
        [root@localhost 0620]#
        [root@localhost 0620]# perf record -e arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,jitter=1,store_filter=1,min_latency=0/ \
      				     -e  cache-misses sleep 1
        [root@localhost 0620]#
      
      The current code can only work if the only event to be traced is an
      'arm_spe_x', or if it is the last event to be specified. Otherwise the
      last event type will be checked against all the arm_spe_pmus[i]->types,
      none will match and an out of bound 'i' index will be used in
      arm_spe_recording_init().
      
      We don't support concurrent multiple arm_spe_x events currently, that
      is checked in arm_spe_recording_options(), and it will show the relevant
      info. So add the check and record of the first found 'arm_spe_pmu' to
      fix this issue here.
      
      Fixes: ffd3d18c ("perf tools: Add ARM Statistical Profiling Extensions (SPE) support")
      Signed-off-by: default avatarWei Li <liwei391@huawei.com>
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Tested-by-by: default avatarLeo Yan <leo.yan@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lore.kernel.org/lkml/20200724071111.35593-2-liwei391@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      bd3c628f
    • Thomas Richter's avatar
      perf tests: Fix test 68 zstd compression for s390 · 463538a3
      Thomas Richter authored
      Commit 5aa98879 ("s390/cpum_sf: prohibit callchain data collection")
      prohibits call graph sampling for hardware events on s390. The
      information recorded is out of context and does not match.
      
      On s390 this commit now breaks test case 68 Zstd perf.data
      compression/decompression.
      
      Therefore omit call graph sampling on s390 in this test.
      
      Output before:
        [root@t35lp46 perf]# ./perf test -Fv 68
        68: Zstd perf.data compression/decompression              :
        --- start ---
        Collecting compressed record file:
        Error:
        cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
                                      Try 'perf stat'
        ---- end ----
        Zstd perf.data compression/decompression: FAILED!
        [root@t35lp46 perf]#
      
      Output after:
      [root@t35lp46 perf]# ./perf test -Fv 68
        68: Zstd perf.data compression/decompression              :
        --- start ---
        Collecting compressed record file:
        500+0 records in
        500+0 records out
        256000 bytes (256 kB, 250 KiB) copied, 0.00615638 s, 41.6 MB/s
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.004 MB /tmp/perf.data.X3M,
                              compressed (original 0.002 MB, ratio is 3.609) ]
        Checking compressed events stats:
        # compressed : Zstd, level = 1, ratio = 4
              COMPRESSED events:          1
        2ELIFREPh---- end ----
        Zstd perf.data compression/decompression: Ok
        [root@t35lp46 perf]#
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarSumanth Korikkar <sumanthk@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Sven Schnelle <svens@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Link: http://lore.kernel.org/lkml/20200729135314.91281-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      463538a3
    • Philippe Duplessis-Guindon's avatar
      tools lib traceevent: Fix memory leak in process_dynamic_array_len · e24c6447
      Philippe Duplessis-Guindon authored
      I compiled with AddressSanitizer and I had these memory leaks while I
      was using the tep_parse_format function:
      
          Direct leak of 28 byte(s) in 4 object(s) allocated from:
              #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
              #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
              #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
              #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
              #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
              #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
              #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
              #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
              #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
              #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
              #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
              #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
              #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
              #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
              #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
              #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
              #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
              #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
              #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
              #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
              #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
              #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
              #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
              #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
              #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
              #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
              #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
      
      The token variable in the process_dynamic_array_len function is
      allocated in the read_expect_type function, but is not freed before
      calling the read_token function.
      
      Free the token variable before calling read_token in order to plug the
      leak.
      Signed-off-by: default avatarPhilippe Duplessis-Guindon <pduplessis@efficios.com>
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e24c6447
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2020-07-31' of git://anongit.freedesktop.org/drm/drm · d8b9faec
      Linus Torvalds authored
      Pull more drm fixes from Dave Airlie:
       "As mentioned previously this contains the nouveau regression fix.
      
        amdgpu had three fixes outstanding as well, one revert, an info leak
        and use after free. The use after free is a bit trickier than I'd
        like, and I've personally gone over it to confirm I'm happy that it is
        doing what it says.
      
        nouveau:
         - final modifiers regression fix
      
        amdgpu:
         - Revert a fix which caused other regressions
         - Fix potential kernel info leak
         - Fix a use-after-free bug that was uncovered by another change in 5.7"
      
      * tag 'drm-fixes-2020-07-31' of git://anongit.freedesktop.org/drm/drm:
        drm/nouveau: Accept 'legacy' format modifiers
        Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"
        drm/amd/display: Clear dm_state for fast updates
        drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
      d8b9faec
    • Dave Airlie's avatar
      Merge tag 'amd-drm-fixes-5.8-2020-07-30' of... · 887c909d
      Dave Airlie authored
      Merge tag 'amd-drm-fixes-5.8-2020-07-30' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      
      amd-drm-fixes-5.8-2020-07-30:
      
      amdgpu:
      - Revert a fix which caused other regressions
      - Fix potential kernel info leak
      - Fix a use-after-free bug that was uncovered by another change in 5.7
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexdeucher@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200730154338.244104-1-alexander.deucher@amd.com
      887c909d
    • James Jones's avatar
      drm/nouveau: Accept 'legacy' format modifiers · faa0fcf9
      James Jones authored
      Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
      family of modifiers to handle broken userspace
      Xorg modesetting and Mesa drivers. Existing Mesa
      drivers are still aware of only these older
      format modifiers which do not differentiate
      between different variations of the block linear
      layout. When the format modifier support flag was
      flipped in the nouveau kernel driver, the X.org
      modesetting driver began attempting to use its
      format modifier-enabled framebuffer path. Because
      the set of format modifiers advertised by the
      kernel prior to this change do not intersect with
      the set of format modifiers advertised by Mesa,
      allocating GBM buffers using format modifiers
      fails and the modesetting driver falls back to
      non-modifier allocation. However, it still later
      queries the modifier of the GBM buffer when
      creating its DRM-KMS framebuffer object, receives
      the old-format modifier from Mesa, and attempts
      to create a framebuffer with it. Since the kernel
      is still not aware of these formats, this fails.
      
      Userspace should not be attempting to query format
      modifiers of GBM buffers allocated with a non-
      format-modifier-aware allocation path, but to
      avoid breaking existing userspace behavior, this
      change accepts the old-style format modifiers when
      creating framebuffers and applying them to planes
      by translating them to the equivalent new-style
      modifier. To accomplish this, some layout
      parameters must be assumed to match properties of
      the device targeted by the relevant ioctls. To
      avoid perpetuating misuse of the old-style
      modifiers, this change does not advertise support
      for them. Doing so would imply compatibility
      between devices with incompatible memory layouts.
      
      Tested with Xorg 1.20 modesetting driver,
      weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
      gnome & KDE wayland desktops from Ubuntu 18.04,
      and sway 1.5
      Reported-by: default avatarKirill A. Shutemov <kirill@shutemov.name>
      Fixes: fa4f4c21 ("drm/nouveau/kms: Support NVIDIA format modifiers")
      Link: https://lkml.org/lkml/2020/6/30/1251Signed-off-by: default avatarJames Jones <jajones@nvidia.com>
      Acked-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      faa0fcf9
  2. 30 Jul, 2020 12 commits
  3. 29 Jul, 2020 13 commits
  4. 28 Jul, 2020 3 commits
  5. 27 Jul, 2020 5 commits