07 Feb, 2019

1 commit

  • commit ed5f13261cb65b02c611ae9971677f33581d4286 upstream.

    Passing EPERM during syscall skipping was confusing since the test wasn't
    actually exercising the errno evaluation -- it was just passing a literal
    "1" (EPERM). Instead, expand the tests to check both direct value returns
    (positive, 45000 in this case), and errno values (negative, -ESRCH in this
    case) to check both fake success and fake failure during syscall skipping.

    Reported-by: Colin Ian King
    Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook
    Signed-off-by: Shuah Khan
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     

31 Jan, 2019

4 commits

  • This reverts commit e65cd9a20343ea90f576c24c38ee85ab6e7d5fec.

    Tommi T. Rrantala notes:

    PTRACE_SECCOMP_GET_METADATA was only added in 4.16
    (26500475ac1b499d8636ff281311d633909f5d20)

    And it's also breaking seccomp_bpf.c compilation for me:

    seccomp_bpf.c: In function ‘get_metadata’:
    seccomp_bpf.c:2878:26: error: storage size of ‘md’ isn’t known
    struct seccomp_metadata md;

    Signed-off-by: Sasha Levin

    Sasha Levin
     
  • [ Upstream commit 1fe627da30331024f453faef04d500079b901107 ]

    libdwfl parses an ELF file itself and creates mappings for the
    individual sections. perf on the other hand sees raw mmap events which
    represent individual sections. When we encounter an address pointing
    into a mapping with pgoff != 0, we must take that into account and
    report the file at the non-offset base address.

    This fixes unwinding with libdwfl in some cases. E.g. for a file like:

    ```

    using namespace std;

    mutex g_mutex;

    double worker()
    {
    lock_guard guard(g_mutex);
    uniform_real_distribution uniform(-1E5, 1E5);
    default_random_engine engine;
    double s = 0;
    for (int i = 0; i < 1000; ++i) {
    s += norm(complex(uniform(engine), uniform(engine)));
    }
    cout << s << endl;
    return s;
    }

    int main()
    {
    vector> results;
    for (int i = 0; i < 10000; ++i) {
    results.push_back(async(launch::async, worker));
    }
    return 0;
    }
    ```

    Compile it with `g++ -g -O2 -lpthread cpp-locking.cpp -o cpp-locking`,
    then record it with `perf record --call-graph dwarf -e
    sched:sched_switch`.

    When you analyze it with `perf script` and libunwind, you should see:

    ```
    cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so)
    7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so)
    7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so)
    7f38e42569e5 __GI___libc_malloc+0x115 (inlined)
    7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined)
    7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined)
    7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined)
    7f38e424df36 _IO_new_file_xsputn+0x116 (inlined)
    7f38e4242bfb __GI__IO_fwrite+0xdb (inlined)
    7f38e463fa6d std::basic_streambuf >::sputn(char const*, long)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator >::_M_put(char const*, long)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator > std::__write(std::ostreambuf_iterator >, char const*, int)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator > std::num_put > >::_M_insert_float(std::ostreambuf_iterator
    7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl>
    7f38e464bd70 std::ostream& std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25)
    563b9cb502f7 std::ostream::operator<(std::__invoke_other, double (*&&)())+0x2b (inlined)
    563b9cb506fb std::__invoke_result::type std::__invoke(double (*&&)())+0x2b (inlined)
    563b9cb506fb decltype (__invoke((_S_declval)())) std::thread::_Invoker >::_M_invoke(std::_Index_tuple)+0x2b (inlined)
    563b9cb506fb std::thread::_Invoker >::operator()()+0x2b (inlined)
    563b9cb506fb std::__future_base::_Task_setter, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker >, dou>
    563b9cb506fb std::_Function_handler (), std::__future_base::_Task_setter
    563b9cb507e8 std::function ()>::operator()() const+0x28 (inlined)
    563b9cb507e8 std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*)+0x28 (/ssd/milian/>
    7f38e46d24fe __pthread_once_slow+0xbe (/usr/lib/libpthread-2.28.so)
    563b9cb51149 __gthread_once+0xe9 (inlined)
    563b9cb51149 void std::call_once ()>*, bool*)>
    563b9cb51149 std::__future_base::_State_baseV2::_M_set_result(std::function ()>, bool)+0xe9 (inlined)
    563b9cb51149 std::__future_base::_Async_state_impl >, double>::_Async_state_impl(std::thread::_Invoker >&&)::{lambda()#1}::op>
    563b9cb51149 void std::__invoke_impl >, double>::_Async_state_impl(std::thread::_Invoker
    563b9cb51149 std::__invoke_result >, double>::_Async_state_impl(std::thread::_Invoker >>
    563b9cb51149 decltype (__invoke((_S_declval)())) std::thread::_Invoker >, double>::_Async_state_>
    563b9cb51149 std::thread::_Invoker >, double>::_Async_state_impl(std::thread::_Invoker
    563b9cb51149 std::thread::_State_impl >, double>::_Async_state_impl(std::thread>
    7f38e45f0062 execute_native_thread_routine+0x12 (/usr/lib/libstdc++.so.6.0.25)
    7f38e46caa9c start_thread+0xfc (/usr/lib/libpthread-2.28.so)
    7f38e42ccb22 __GI___clone+0x42 (inlined)
    ```

    Before this patch, using libdwfl, you would see:

    ```
    cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so)
    a041161e77950c5c [unknown] ([unknown])
    ```

    With this patch applied, we get a bit further in unwinding:

    ```
    cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux)
    7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so)
    7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so)
    7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so)
    7f38e42569e5 __GI___libc_malloc+0x115 (inlined)
    7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined)
    7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined)
    7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined)
    7f38e424df36 _IO_new_file_xsputn+0x116 (inlined)
    7f38e4242bfb __GI__IO_fwrite+0xdb (inlined)
    7f38e463fa6d std::basic_streambuf >::sputn(char const*, long)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator >::_M_put(char const*, long)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator > std::__write(std::ostreambuf_iterator >, char const*, int)+0x1cd (inlined)
    7f38e463fa6d std::ostreambuf_iterator > std::num_put > >::_M_insert_float(std::ostreambuf_iterator
    7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl>
    7f38e464bd70 std::ostream& std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25)
    563b9cb502f7 std::ostream::operator<
    Acked-by: Jiri Olsa
    Link: http://lkml.kernel.org/r/20181029141644.3907-1-milian.wolff@kdab.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Milian Wolff
     
  • [ Upstream commit 3d20c6246690219881786de10d2dda93f616d0ac ]

    Path passed to libdw for unwinding doesn't include symfs path
    if specified, so unwinding fails because ELF file is not found.

    Similar to unwinding with libunwind, pass symsrc_filename instead
    of long_name. If there is no symsrc_filename, fallback to long_name.

    Signed-off-by: Martin Vuille
    Cc: Adrian Hunter
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Wang Nan
    Link: http://lkml.kernel.org/r/20180211212420.18388-1-jpmv27@aim.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Martin Vuille
     
  • commit e1812933b17be7814f51b6c310c5d1ced7a9a5f5 upstream.

    There was a bug where the per-mm pkey state was not being preserved across
    fork() in the child. fork() is performed in the pkey selftests, but all of
    the pkey activity is performed in the parent. The child does not perform
    any actions sensitive to pkey state.

    To make the test more sensitive to these kinds of bugs, add a fork() where
    the parent exits, and execution continues in the child.

    To achieve this let the key exhaustion test not terminate at the first
    allocation failure and fork after 2*NR_PKEYS loops and continue in the
    child.

    Signed-off-by: Dave Hansen
    Signed-off-by: Thomas Gleixner
    Cc: bp@alien8.de
    Cc: hpa@zytor.com
    Cc: peterz@infradead.org
    Cc: mpe@ellerman.id.au
    Cc: will.deacon@arm.com
    Cc: luto@kernel.org
    Cc: jroedel@suse.de
    Cc: stable@vger.kernel.org
    Cc: Borislav Petkov
    Cc: "H. Peter Anvin"
    Cc: Peter Zijlstra
    Cc: Michael Ellerman
    Cc: Will Deacon
    Cc: Andy Lutomirski
    Cc: Joerg Roedel
    Link: https://lkml.kernel.org/r/20190102215657.585704B7@viggo.jf.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Dave Hansen
     

26 Jan, 2019

5 commits

  • [ Upstream commit ece9804985b57e1ccd83b1fb6288520955a29d51 ]

    At some point we decided not to directly include kernel sources files
    when building tools/perf/, but when tools/lib/subcmd/ was forked from
    tools/perf it somehow ended up adding it via these two lines in its
    Makefile:

    CFLAGS += -I$(srctree)/include/uapi
    CFLAGS += -I$(srctree)/include

    As $(srctree) points to the kernel sources.

    Removing those lines and keeping just:

    CFLAGS += -I$(srctree)/tools/include/

    Is enough to build tools/perf and tools/objtool.

    This fixes the build when building from the sources in environments such
    as the Android NDK crossbuilding from a fedora:26 system:

    subcmd-util.h:11:15: error: expected ',' or ';' before 'void'
    static inline void report(const char *prefix, const char *err, va_list params)
    ^
    In file included from /git/perf/include/uapi/linux/stddef.h:2:0,
    from /git/perf/include/uapi/linux/posix_types.h:5,
    from /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/sys/types.h:36,
    from /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/unistd.h:33,
    from run-command.c:2:
    subcmd-util.h:18:17: error: '__no_instrument_function__' attribute applies only to functions

    The /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/sys/types.h
    file that includes linux/posix_types.h ends up getting the one in the kernel
    sources causing the breakage. Fix it.

    Test built tools/objtool/ too.

    Reported-by: Jiri Olsa
    Tested-by: Jiri Olsa
    Cc: Adrian Hunter
    Cc: Josh Poimboeuf
    Cc: Namhyung Kim
    Fixes: 4b6ab94eabe4 ("perf subcmd: Create subcmd library")
    Link: https://lkml.kernel.org/n/tip-5lhaoecrj12t0bqwvpiu14sm@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Arnaldo Carvalho de Melo
     
  • [ Upstream commit bd8d57fb7e25e9fcf67a9eef5fa13aabe2016e07 ]

    The strncpy() function may leave the destination string buffer
    unterminated, better use strlcpy() that we have a __weak fallback
    implementation for systems without it.

    This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

    util/parse-events.c: In function 'print_symbol_events':
    util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
    strncpy(name, syms->symbol, MAX_NAME_LEN);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In function 'print_symbol_events.constprop',
    inlined from 'print_events' at util/parse-events.c:2508:2:
    util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
    strncpy(name, syms->symbol, MAX_NAME_LEN);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In function 'print_symbol_events.constprop',
    inlined from 'print_events' at util/parse-events.c:2511:2:
    util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
    strncpy(name, syms->symbol, MAX_NAME_LEN);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors

    Cc: Adrian Hunter
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Fixes: 947b4ad1d198 ("perf list: Fix max event string size")
    Link: https://lkml.kernel.org/n/tip-b663e33bm6x8hrkie4uxh7u2@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Arnaldo Carvalho de Melo
     
  • [ Upstream commit 2f5302533f306d5ee87bd375aef9ca35b91762cb ]

    The strncpy() function may leave the destination string buffer
    unterminated, better use strlcpy() that we have a __weak fallback
    implementation for systems without it.

    In this specific case this would only happen if fgets() was buggy, as
    its man page states that it should read one less byte than the size of
    the destination buffer, so that it can put the nul byte at the end of
    it, so it would never copy 255 non-nul chars, as fgets reads into the
    orig buffer at most 254 non-nul chars and terminates it. But lets just
    switch to strlcpy to keep the original intent and silence the gcc 8.2
    warning.

    This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

    In function 'cpu_model',
    inlined from 'svg_cpu_box' at util/svghelper.c:378:2:
    util/svghelper.c:337:5: error: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Werror=stringop-truncation]
    strncpy(cpu_m, &buf[13], 255);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Cc: Adrian Hunter
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Arjan van de Ven
    Fixes: f48d55ce7871 ("perf: Add a SVG helper library file")
    Link: https://lkml.kernel.org/n/tip-xzkoo0gyr56gej39ltivuh9g@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Arnaldo Carvalho de Melo
     
  • [ Upstream commit 1c6f709b9f96366cc47af23c05ecec9b8c0c392d ]

    Users should never use 'pt=0', but if they do it may give a meaningless
    error:

    $ perf record -e intel_pt/pt=0/u uname
    Error:
    The sys_perf_event_open() syscall returned with 22 (Invalid argument) for
    event (intel_pt/pt=0/u).

    Fix that by forcing 'pt=1'.

    Committer testing:

    # perf record -e intel_pt/pt=0/u uname
    Error:
    The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (intel_pt/pt=0/u).
    /bin/dmesg | grep -i perf may provide additional information.

    # perf record -e intel_pt/pt=0/u uname
    pt=0 doesn't make sense, forcing pt=1
    Linux
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.020 MB perf.data ]
    #

    Signed-off-by: Adrian Hunter
    Tested-by: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Link: http://lkml.kernel.org/r/b7c5b4e5-9497-10e5-fd43-5f3e4a0fe51d@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • [ Upstream commit b708a3cc9600390ccaa2b68a88087dd265154b2b ]

    I've stumbled over the current macro-expand behaviour of the test
    harness:

    $ gcc -Wall -xc - <:4:global.macro:Expected 0 (0) != (((signed char) (((status) & 0x7f) + 1) >> 1) > 0) (0)
    global.macro: Test terminated by assertion
    [ FAIL ] global.macro
    [==========] 0 / 1 tests passed.
    [ FAILED ]

    With this change the output of the same test looks much more
    comprehensible:

    [==========] Running 1 tests from 1 test cases.
    [ RUN ] global.macro
    :4:global.macro:Expected 0 (0) != WIFSIGNALED(status) (0)
    global.macro: Test terminated by assertion
    [ FAIL ] global.macro
    [==========] 0 / 1 tests passed.
    [ FAILED ]

    The issue is very similar to the bug fixed in glibc assert(3)
    three years ago:
    https://sourceware.org/bugzilla/show_bug.cgi?id=18604

    Cc: Shuah Khan
    Cc: Kees Cook
    Cc: Andy Lutomirski
    Cc: Will Drewry
    Cc: linux-kselftest@vger.kernel.org
    Signed-off-by: Dmitry V. Levin
    Acked-by: Kees Cook
    Signed-off-by: Shuah Khan
    Signed-off-by: Sasha Levin

    Dmitry V. Levin
     

13 Jan, 2019

4 commits

  • commit 755396163148b50fe1afb4bdd3365e47f3ff7a42 upstream.

    Commit 7ed1c1901fe5 (tools: fix cross-compile var clobbering) removed
    setting of LD to $(CROSS_COMPILE)gcc. This broke build of acpica
    (acpidump) in power/acpi:
    ld: unrecognized option '-D_LINUX'

    The tools pass CFLAGS to the linker (incl. -D_LINUX), so revert this
    particular change and let LD be $(CC) again. Note that the old behaviour
    was a bit different, it used $(CROSS_COMPILE)gcc which was eliminated by
    the commit 7ed1c1901fe5. We use $(CC) for that reason.

    Fixes: 7ed1c1901fe5 (tools: fix cross-compile var clobbering)
    Signed-off-by: Jiri Slaby
    Cc: 4.16+ # 4.16+
    Signed-off-by: Rafael J. Wysocki
    Cc: Sudip Mukherjee
    Cc: Martin Kelly
    Signed-off-by: Greg Kroah-Hartman

    Jiri Slaby
     
  • commit 808153e1187fa77ac7d7dad261ff476888dcf398 upstream.

    devm_memremap_pages() is a facility that can create struct page entries
    for any arbitrary range and give drivers the ability to subvert core
    aspects of page management.

    Specifically the facility is tightly integrated with the kernel's memory
    hotplug functionality. It injects an altmap argument deep into the
    architecture specific vmemmap implementation to allow allocating from
    specific reserved pages, and it has Linux specific assumptions about page
    structure reference counting relative to get_user_pages() and
    get_user_pages_fast(). It was an oversight and a mistake that this was
    not marked EXPORT_SYMBOL_GPL from the outset.

    Again, devm_memremap_pagex() exposes and relies upon core kernel internal
    assumptions and will continue to evolve along with 'struct page', memory
    hotplug, and support for new memory types / topologies. Only an in-kernel
    GPL-only driver is expected to keep up with this ongoing evolution. This
    interface, and functionality derived from this interface, is not suitable
    for kernel-external drivers.

    Link: http://lkml.kernel.org/r/154275557457.76910.16923571232582744134.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams
    Reviewed-by: Christoph Hellwig
    Acked-by: Michal Hocko
    Cc: "Jérôme Glisse"
    Cc: Balbir Singh
    Cc: Logan Gunthorpe
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Dan Williams
     
  • commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.

    Currently a number of Makefiles break when used with toolchains that
    pass extra flags in CC and other cross-compile related variables (such
    as --sysroot).

    Thus we get this error when we use a toolchain that puts --sysroot in
    the CC var:

    ~/src/linux/tools$ make iio
    [snip]
    iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
    #include
    ^~~~~~~~~~

    This occurs because we clobber several env vars related to
    cross-compiling with lines like this:

    CC = $(CROSS_COMPILE)gcc

    Although this will point to a valid cross-compiler, we lose any extra
    flags that might exist in the CC variable, which can break toolchains
    that rely on them (for example, those that use --sysroot).

    This easily shows up using a Yocto SDK:

    $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CC
    arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
    -mcpu=cortex-a8
    --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CROSS_COMPILE
    arm-poky-linux-gnueabi-

    $ echo ${CROSS_COMPILE}gcc
    krm-poky-linux-gnueabi-gcc

    Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
    --sysroot and other flags that enable us to find the right libraries to
    link against, so we can't find unistd.h and other libraries and headers.
    Normally with the --sysroot flag we would find unistd.h in the sdk
    directory in the sysroot:

    $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
    [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h

    The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
    already set, and it compiles correctly with the above toolchain.

    So, generalize the logic that perf uses in the common Makefile and
    remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.

    Note that this patch does not fix cross-compile for all the tools (some
    have other bugs), but it does fix it for all except usb and acpi, which
    still have other unrelated issues.

    I tested both with and without the patch on native and cross-build and
    there appear to be no regressions.

    Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com
    Signed-off-by: Martin Kelly
    Acked-by: Mark Brown
    Cc: Tejun Heo
    Cc: Li Zefan
    Cc: Johannes Weiner
    Cc: Linus Walleij
    Cc: "K. Y. Srinivasan"
    Cc: Haiyang Zhang
    Cc: Stephen Hemminger
    Cc: Jonathan Cameron
    Cc: Pali Rohar
    Cc: Richard Purdie
    Cc: Jacek Anaszewski
    Cc: Pavel Machek
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Arnaldo Carvalho de Melo
    Cc: Robert Moore
    Cc: Lv Zheng
    Cc: "Rafael J. Wysocki"
    Cc: Greg Kroah-Hartman
    Cc: Valentina Manea
    Cc: Shuah Khan
    Cc: Mario Limonciello
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Cc: Ignat Korchagin
    Signed-off-by: Greg Kroah-Hartman

    Martin Kelly
     
  • [ Upstream commit c5c08bed843c2b2c048c16d1296d7631d7c1620e ]

    Fixes: d38499530e5 ("fs: decouple READ and WRITE from the block layer ops")
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Sasha Levin

    Michael S. Tsirkin
     

10 Jan, 2019

1 commit

  • commit 11a64a05dc649815670b1be9fe63d205cb076401 upstream.

    Depending on which functions are inlined in util/pmu.c, the snprintf()
    calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
    warning:

    util/pmu.c: In function 'pmu_aliases':
    util/pmu.c:178:31: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
    snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
    ^~

    I found this when trying to build perf from Linux 3.16 with gcc 8.
    However I can reproduce the problem in mainline if I force
    __perf_pmu__new_alias() to be inlined.

    Suppress this by using scnprintf() as has been done elsewhere in perf.

    Signed-off-by: Ben Hutchings
    Cc: Alexander Shishkin
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20181111184524.fux4taownc6ndbx6@decadent.org.uk
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     

29 Dec, 2018

1 commit

  • [ Upstream commit a2015516c5c0be932a69e1d3405c2fb03b4eacf1 ]

    We need to synthesize events first, because some features works on top
    of them (on report side).

    Signed-off-by: Jiri Olsa
    Tested-by: Stephane Eranian
    Cc: Alexander Shishkin
    Cc: David Ahern
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20180314092205.23291-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Jiri Olsa
     

21 Dec, 2018

1 commit

  • [ Upstream commit c01ac66b38660f2b507ccd0b75d28e3002d56fbb ]

    The message got changed a lot time ago.

    This was responsible for 36 test case failures on sparc64.

    Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
    Signed-off-by: David S. Miller
    Signed-off-by: Alexei Starovoitov
    Signed-off-by: Sasha Levin

    David Miller
     

17 Dec, 2018

4 commits

  • [ Upstream commit 22566c1603030f0a036ad564634b064ad1a55db2 ]

    Because find_symbol_by_name() traverses the same lists as
    read_symbols(), changing sym->name in place without copying it affects
    the result of find_symbol_by_name(). In the case where a ".cold"
    function precedes its parent in sec->symbol_list, it can result in a
    function being considered a parent of itself. This leads to function
    length being set to 0 and other consequent side-effects including a
    segfault in add_switch_table(). The effects of this bug are only
    visible when building with -ffunction-sections in KCFLAGS.

    Fix by copying the search string instead of modifying it in place.

    Signed-off-by: Artem Savkov
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")
    Link: http://lkml.kernel.org/r/910abd6b5a4945130fd44f787c24e07b9e07c8da.1542736240.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin

    Artem Savkov
     
  • [ Upstream commit 0b9301fb632f7111a3293a30cc5b20f1b82ed08d ]

    If read_symbols() fails during second list traversal (the one dealing
    with ".cold" subfunctions) it frees the symbol, but never deletes it
    from the list/hash_table resulting in symbol being freed again in
    elf_close(). Fix it by just returning an error, leaving cleanup to
    elf_close().

    Signed-off-by: Artem Savkov
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")
    Link: http://lkml.kernel.org/r/beac5a9b7da9e8be90223459dcbe07766ae437dd.1542736240.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin

    Artem Savkov
     
  • [ Upstream commit b01c1f69c8660eaeab7d365cd570103c5c073a02 ]

    When reporting on 'record' server we try to retrieve/use the mnt
    namespace of the profiled tasks. We use following API with cookie to
    hold the return namespace, roughly:

    nsinfo__mountns_enter(struct nsinfo *nsi, struct nscookie *nc)
    setns(newns, 0);
    ...
    new ns related open..
    ...
    nsinfo__mountns_exit(struct nscookie *nc)
    setns(nc->oldns)

    Once finished we setns to old namespace, which also sets the current
    working directory (cwd) to "/", trashing the cwd we had.

    This is mostly fine, because we use absolute paths almost everywhere,
    but it screws up 'perf diff':

    # perf diff
    failed to open perf.data: No such file or directory (try 'perf record' first)
    ...

    Adding the current working directory to be part of the cookie and
    restoring it in the nsinfo__mountns_exit call.

    Signed-off-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Krister Johansen
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Fixes: 843ff37bb59e ("perf symbols: Find symbols in different mount namespace")
    Link: http://lkml.kernel.org/r/20181101170001.30019-1-jolsa@kernel.org
    [ No need to check for NULL args for free(), use zfree() for struct members ]
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Jiri Olsa
     
  • [ Upstream commit 25d8bcedbf4329895dbaf9dd67baa6f18dad918c ]

    Start flood ping for each cpu while loading/flushing rulesets to make
    sure we do not access already-free'd rules from nf_tables evaluation loop.

    Also add this to TARGETS so 'make run_tests' in selftest dir runs it
    automatically.

    This would have caught the bug fixed in previous change
    ("netfilter: nf_tables: do not skip inactive chains during generation update")
    sooner.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Sasha Levin

    Florian Westphal
     

01 Dec, 2018

1 commit


27 Nov, 2018

7 commits

  • commit f6c66d73bb8192d357bb5fb8cd5826920f811d8c upstream.

    The "Object code reading" test will not create maps for the PTI entry
    trampolines unless the machine environment exists to show that the arch is
    x86_64.

    Signed-off-by: Adrian Hunter
    Reported-by: Arnaldo Carvalho de Melo
    Tested-by: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Link: http://lkml.kernel.org/r/1528183800-21577-1-git-send-email-adrian.hunter@intel.com
    [ split from a larger patch ]
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • commit 4d99e4136580d178e3523281a820be17bf814bf8 upstream.

    On x86_64 the PTI entry trampolines are not in the kernel map created by
    perf tools. That results in the addresses having no symbols and prevents
    annotation. It also causes Intel PT to have decoding errors at the
    trampoline addresses.

    Workaround that by creating maps for the trampolines.

    At present the kernel does not export information revealing where the
    trampolines are. Until that happens, the addresses are hardcoded.

    Signed-off-by: Adrian Hunter
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: H. Peter Anvin
    Cc: Jiri Olsa
    Cc: Joerg Roedel
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/1526986485-6562-6-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • commit 9cecca325ea879c84fcd31a5e609a514c1a1dbd1 upstream.

    Add a function to return the number of the machine's available CPUs.

    Signed-off-by: Adrian Hunter
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: H. Peter Anvin
    Cc: Jiri Olsa
    Cc: Joerg Roedel
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/1526986485-6562-5-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • commit 19422a9f2a3be7f3a046285ffae4cbb571aa853a upstream.

    On x86_64, PTI entry trampolines are less than the start of kernel text,
    but still above 2^63. So leave kernel_start = 1ULL << 63 for x86_64.

    Signed-off-by: Adrian Hunter
    Tested-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: H. Peter Anvin
    Cc: Joerg Roedel
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/1526548928-20790-7-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • commit dbbd34a666ee117d0e39e71a47f38f02c4a5c698 upstream.

    Add a function to identify the machine architecture.

    Signed-off-by: Adrian Hunter
    Tested-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: Andy Lutomirski
    Cc: Dave Hansen
    Cc: H. Peter Anvin
    Cc: Joerg Roedel
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: x86@kernel.org
    Link: http://lkml.kernel.org/r/1526548928-20790-6-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Adrian Hunter
     
  • [ Upstream commit 6ac2226229d931153331a93d90655a3de05b9290 ]

    Currently jvmti agent can not be used because function scnprintf is not
    present in the agent libperf-jvmti.so. As a result the JVM when using
    such agent to record JITed code profiling information will fail on
    looking up scnprintf:

    java: symbol lookup error: lib/libperf-jvmti.so: undefined symbol: scnprintf

    This commit fixes that by reverting to the use of snprintf, that can be
    looked up, instead of scnprintf, adding a proper check for the returned
    value in order to print a better error message when the jitdump file
    pathname is too long. Checking the returned value also helps to comply
    with some recent gcc versions, like gcc8, which will fail due to
    truncated writing checks related to the -Werror=format-truncation= flag.

    Signed-off-by: Gustavo Romero
    Acked-by: Jiri Olsa
    LPU-Reference: 1541117601-18937-2-git-send-email-gromero@linux.vnet.ibm.com
    Link: https://lkml.kernel.org/n/tip-mvpxxxy7wnzaj74cq75muw3f@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    Gustavo Romero
     
  • [ Upstream commit d6afa561e1471ccfdaf7191230c0c59a37e45a5b ]

    Using the sh_entsize for both values isn't correct. It happens to be
    correct on x86...

    For both 32-bit and 64-bit sparc, there are four PLT entries in the PLT
    section.

    Signed-off-by: David S. Miller
    Cc: Alexander Shishkin
    Cc: Alexis Berlemont
    Cc: David Tolnay
    Cc: Hanjun Guo
    Cc: Hemant Kumar
    Cc: Li Bin
    Cc: Masami Hiramatsu
    Cc: Milian Wolff
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Wang Nan
    Cc: zhangmengting@huawei.com
    Fixes: b2f7605076d6 ("perf symbols: Fix plt entry calculation for ARM and AARCH64")
    Link: http://lkml.kernel.org/r/20181017.120859.2268840244308635255.davem@davemloft.net
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin

    David Miller
     

21 Nov, 2018

1 commit

  • [ Upstream commit 693b31b2fc1636f0aa7af53136d3b49f6ad9ff39 ]

    Test tm-tmspr might exit before all threads stop executing, because it just
    waits for the very last thread to join before proceeding/exiting.

    This patch makes sure that all threads that were created will join before
    proceeding/exiting.

    This patch also guarantees that the amount of threads being created is equal
    to thread_num.

    Signed-off-by: Breno Leitao
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Breno Leitao
     

14 Nov, 2018

10 commits

  • commit 48dc0ef19044bfb69193302fbe3a834e3331b7ae upstream.

    Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
    fault that happens on the child process prior to setting cptr[2] = 1. This
    causes the parent process to wait forever at 'while (!pptr[2])' and the test to
    be killed by the test harness framework by timeout, thus, failing.

    The segmentation fault happens because of a inline assembly being
    generated as:

    0x10000355c lfs f0, 0(0)

    This is reading memory position 0x0 and causing the segmentation fault.

    This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
    flt_4 is passed to the inline assembly block as:

    [flt_4] "r" (&d)

    Since the inline assembly 'r' constraint means any GPR, gpr0 is being
    chosen, thus causing this issue when issuing a Load Floating-Point Single
    instruction.

    This patch simply changes the constraint to 'b', which specify that this
    register will be used as base, and r0 is not allowed to be used, avoiding
    this issue.

    Other than that, removing flt_2 register from the input operands, since it
    is not used by the inline assembly code at all.

    Cc: stable@vger.kernel.org
    Signed-off-by: Breno Leitao
    Acked-by: Segher Boessenkool
    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Breno Leitao
     
  • [ Upstream commit 8c22e2f695920ebd94f9a53bcf2a65eb36d4dba1 ]

    The msr_pstate data is only 63 bits long and should be 64 bits.

    Add in the missing bit from res1 for AMD Family 0x17.

    Reference: https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf, page 138.

    Signed-off-by: Prarit Bhargava
    Cc: Shuah Khan
    Cc: Stafford Horne
    Signed-off-by: Shuah Khan (Samsung OSG)
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Prarit Bhargava
     
  • [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]

    cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
    (0xC0010064 + state number) set to zero. As a result fid and did are zero
    and the crash occurs because of a divide by zero (cof = fid/did). This
    can be prevented by checking the enable bit in the PStateDef MSR before
    calculating cof. By doing this the value of pstate[i] remains zero and
    the value can be tested before displaying the active Pstates.

    Check the enable bit in the PstateDef register for all supported families
    and only print out enabled Pstates.

    Signed-off-by: Prarit Bhargava
    Cc: Shuah Khan
    Cc: Stafford Horne
    Signed-off-by: Shuah Khan (Samsung OSG)
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Prarit Bhargava
     
  • [ Upstream commit ce49d8436cffa9b7a6a5f110879d53e89dbc6746 ]

    Ensure that all code paths in strbuf_addv() call va_end() on the
    ap_saved copy that was made.

    Fixes the following coverity complaint:

    Error: VARARGS (CWE-237): [#def683]
    tools/perf/util/strbuf.c:106: missing_va_end: va_end was not called
    for "ap_saved".

    Signed-off-by: Sanskriti Sharma
    Reviewed-by: Jiri Olsa
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/1538490554-8161-2-git-send-email-sansharm@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sanskriti Sharma
     
  • [ Upstream commit faedbf3fd19f2511a39397f76359e4cc6ee93072 ]

    Free tracing_data structure in tracing_data_get() error paths.

    Fixes the following coverity complaint:

    Error: RESOURCE_LEAK (CWE-772):
    leaked_storage: Variable "tdata" going out of scope leaks the storage

    Signed-off-by: Sanskriti Sharma
    Reviewed-by: Jiri Olsa
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/1538490554-8161-3-git-send-email-sansharm@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sanskriti Sharma
     
  • [ Upstream commit 1e44224fb0528b4c0cc176bde2bb31e9127eb14b ]

    For each system in a given pevent, read_event_files() reads in a
    temporary 'sys' string. Be sure to free this string before moving onto
    to the next system and/or leaving read_event_files().

    Fixes the following coverity complaints:

    Error: RESOURCE_LEAK (CWE-772):

    tools/perf/util/trace-event-read.c:343: overwrite_var: Overwriting
    "sys" in "sys = read_string()" leaks the storage that "sys" points to.

    tools/perf/util/trace-event-read.c:353: leaked_storage: Variable "sys"
    going out of scope leaks the storage it points to.

    Signed-off-by: Sanskriti Sharma
    Reviewed-by: Jiri Olsa
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/1538490554-8161-6-git-send-email-sansharm@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sanskriti Sharma
     
  • [ Upstream commit ba0e41ca81b935b958006c7120466e2217357827 ]

    Add a testcase to check the syntax and field types for
    synthetic_events interface.

    Link: http://lkml.kernel.org/r/153986838264.18251.16627517536956299922.stgit@devbox

    Acked-by: Shuah Khan
    Signed-off-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt (VMware)
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Masami Hiramatsu
     
  • [ Upstream commit 0ed149cf5239cc6e7e65bf00f769e8f1e91076c0 ]

    The size of the resulting cpu map can be smaller than a multiple of
    sizeof(u64), resulting in SIGBUS on cpus like Sparc as the next event
    will not be aligned properly.

    Signed-off-by: David S. Miller
    Cc: Jiri Olsa
    Cc: Kan Liang
    Fixes: 6c872901af07 ("perf cpu_map: Add cpu_map event synthesize function")
    Link: http://lkml.kernel.org/r/20181011.224655.716771175766946817.davem@davemloft.net
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Miller
     
  • [ Upstream commit 36b8d4628d3cc8f5a748e508cce8673bc00fc63c ]

    When a build is run from something like a cron job, the user's $PATH is
    rather minimal, of note, not including /usr/sbin in my own case. Because
    of that, an automated rpm package build ultimately fails to find
    libperf-jvmti.so, because somewhere within the build, this happens...

    /bin/sh: alternatives: command not found
    /bin/sh: alternatives: command not found
    Makefile.config:849: No openjdk development package found, please install
    JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel

    ...and while the build continues, libperf-jvmti.so isn't built, and
    things fall down when rpm tries to find all the %files specified. Exact
    same system builds everything just fine when the job is launched from a
    login shell instead of a cron job, since alternatives is in $PATH, so
    openjdk is actually found.

    The test required to get into this section of code actually specifies
    the full path, as does a block just above it, so let's do that here too.

    Signed-off-by: Jarod Wilson
    Acked-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: William Cohen
    Fixes: d4dfdf00d43e ("perf jvmti: Plug compilation into perf build")
    Link: http://lkml.kernel.org/r/20180906221812.11167-1-jarod@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jarod Wilson
     
  • [ Upstream commit 94aafb74cee0002e2f2eb6dc5376f54d5951ab4d ]

    Michael reported that he could not stat following event:

    $ perf stat -e unc_p_freq_ge_1200mhz_cycles -a -- ls
    event syntax error: '..e_1200mhz_cycles'
    \___ value too big for format, maximum is 255
    Run 'perf list' for a list of valid events

    The event is unwrapped into:

    uncore_pcu/event=0xb,filter_band0=1200/

    where filter_band0 format says it's one byte only:

    # cat uncore_pcu/format/filter_band0
    config1:0-7

    while JSON files specifies bigger number:

    "Filter": "filter_band0=1200",

    all the filter_band* formats show 1 byte width:

    # cat uncore_pcu/format/filter_band1
    config1:8-15
    # cat uncore_pcu/format/filter_band2
    config1:16-23
    # cat uncore_pcu/format/filter_band3
    config1:24-31

    The reason of the issue is that filter_band* values are supposed to be
    in 100Mhz units.. it's stated in the JSON help for the events, like:

    filter_band3=XXX, with XXX in 100Mhz units

    This patch divides the filter_band* values by 100, plus there's couple
    of changes that actually change the number completely, like:

    - "Filter": "edge=1,filter_band2=4000",
    + "Filter": "edge=1,filter_band2=30",

    Reported-by: Michael Petlan
    Signed-off-by: Jiri Olsa
    Acked-by: Andi Kleen
    Cc: Alexander Shishkin
    Cc: Kan Liang
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20181010080339.GB15790@krava
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jiri Olsa