1. 21 Oct, 2021 1 commit
  2. 20 Oct, 2021 2 commits
  3. 19 Oct, 2021 1 commit
  4. 14 Oct, 2021 1 commit
  5. 01 Oct, 2021 1 commit
  6. 27 Sep, 2021 1 commit
  7. 24 Sep, 2021 9 commits
  8. 20 Sep, 2021 2 commits
    • Linus Torvalds's avatar
      Linux 5.15-rc2 · e4e737bb
      Linus Torvalds authored
      e4e737bb
    • Linus Torvalds's avatar
      pci_iounmap'2: Electric Boogaloo: try to make sense of it all · 316e8d79
      Linus Torvalds authored
      Nathan Chancellor reports that the recent change to pci_iounmap in
      commit 9caea000 ("parisc: Declare pci_iounmap() parisc version only
      when CONFIG_PCI enabled") causes build errors on arm64.
      
      It took me about two hours to convince myself that I think I know what
      the logic of that mess of #ifdef's in the <asm-generic/io.h> header file
      really aim to do, and rewrite it to be easier to follow.
      
      Famous last words.
      
      Anyway, the code has now been lifted from that grotty header file into
      lib/pci_iomap.c, and has fairly extensive comments about what the logic
      is.  It also avoids indirecting through another confusing (and badly
      named) helper function that has other preprocessor config conditionals.
      
      Let's see what odd architecture did something else strange in this area
      to break things.  But my arm64 cross build is clean.
      
      Fixes: 9caea000 ("parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled")
      Reported-by: default avatarNathan Chancellor <nathan@kernel.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Ulrich Teichert <krypton@ulrich-teichert.org>
      Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      316e8d79
  9. 19 Sep, 2021 18 commits
  10. 18 Sep, 2021 4 commits
    • Linus Torvalds's avatar
      alpha: move __udiv_qrnnd library function to arch/alpha/lib/ · d4d016ca
      Linus Torvalds authored
      We already had the implementation for __udiv_qrnnd (unsigned divide for
      multi-precision arithmetic) as part of the alpha math emulation code.
      
      But you can disable the math emulation code - even if you shouldn't -
      and then the MPI code that actually wants this functionality (and is
      needed by various crypto functions) will fail to build.
      
      So move the extended-precision divide code to be a regular library
      function, just like all the regular division code is.  That way ie is
      available regardless of math-emulation.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4d016ca
    • Linus Torvalds's avatar
      alpha: mark 'Jensen' platform as no longer broken · ab41f75e
      Linus Torvalds authored
      Ok, it almost certainly is still broken on actual hardware, but the
      immediate reason for it having been marked BROKEN was a build error that
      is fixed by just making sure the low-level IO header file is included
      sufficiently early that the __EXTERN_INLINE hackery takes effect.
      
      This was marked broken back in 2017 by commit 1883c9f4 ("alpha: mark
      jensen as broken"), but Ulrich Teichert made me look at it as part of my
      cross-build work to make sure -Werror actually does the right thing.
      
      There are lots of alpha configurations that do not build cleanly, but
      now it's no longer because Jensen wouldn't be buildable.  That said,
      because the Jensen platform doesn't force PCI to be enabled (Jensen only
      had EISA), it ends up being somewhat interesting as a source of odd
      configs.
      Reported-by: default avatarUlrich Teichert <krypton@ulrich-teichert.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab41f75e
    • Andrii Nakryiko's avatar
      perf bpf: Ignore deprecation warning when using libbpf's btf__get_from_id() · 219d720e
      Andrii Nakryiko authored
      Perf code re-implements libbpf's btf__load_from_kernel_by_id() API as
      a weak function, presumably to dynamically link against old version of
      libbpf shared library. Unfortunately this causes compilation warning
      when perf is compiled against libbpf v0.6+.
      
      For now, just ignore deprecation warning, but there might be a better
      solution, depending on perf's needs.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: kernel-team@fb.com
      LPU-Reference: 20210914170004.4185659-1-andrii@kernel.org
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      219d720e
    • Ian Rogers's avatar
      libperf evsel: Make use of FD robust. · aba5daeb
      Ian Rogers authored
      FD uses xyarray__entry that may return NULL if an index is out of
      bounds. If NULL is returned then a segv happens as FD unconditionally
      dereferences the pointer. This was happening in a case of with perf
      iostat as shown below. The fix is to make FD an "int*" rather than an
      int and handle the NULL case as either invalid input or a closed fd.
      
        $ sudo gdb --args perf stat --iostat  list
        ...
        Breakpoint 1, perf_evsel__alloc_fd (evsel=0x5555560951a0, ncpus=1, nthreads=1) at evsel.c:50
        50      {
        (gdb) bt
         #0  perf_evsel__alloc_fd (evsel=0x5555560951a0, ncpus=1, nthreads=1) at evsel.c:50
         #1  0x000055555585c188 in evsel__open_cpu (evsel=0x5555560951a0, cpus=0x555556093410,
            threads=0x555556086fb0, start_cpu=0, end_cpu=1) at util/evsel.c:1792
         #2  0x000055555585cfb2 in evsel__open (evsel=0x5555560951a0, cpus=0x0, threads=0x555556086fb0)
            at util/evsel.c:2045
         #3  0x000055555585d0db in evsel__open_per_thread (evsel=0x5555560951a0, threads=0x555556086fb0)
            at util/evsel.c:2065
         #4  0x00005555558ece64 in create_perf_stat_counter (evsel=0x5555560951a0,
            config=0x555555c34700 <stat_config>, target=0x555555c2f1c0 <target>, cpu=0) at util/stat.c:590
         #5  0x000055555578e927 in __run_perf_stat (argc=1, argv=0x7fffffffe4a0, run_idx=0)
            at builtin-stat.c:833
         #6  0x000055555578f3c6 in run_perf_stat (argc=1, argv=0x7fffffffe4a0, run_idx=0)
            at builtin-stat.c:1048
         #7  0x0000555555792ee5 in cmd_stat (argc=1, argv=0x7fffffffe4a0) at builtin-stat.c:2534
         #8  0x0000555555835ed3 in run_builtin (p=0x555555c3f540 <commands+288>, argc=3,
            argv=0x7fffffffe4a0) at perf.c:313
         #9  0x0000555555836154 in handle_internal_command (argc=3, argv=0x7fffffffe4a0) at perf.c:365
         #10 0x000055555583629f in run_argv (argcp=0x7fffffffe2ec, argv=0x7fffffffe2e0) at perf.c:409
         #11 0x0000555555836692 in main (argc=3, argv=0x7fffffffe4a0) at perf.c:539
        ...
        (gdb) c
        Continuing.
        Error:
        The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_iio_0/event=0x83,umask=0x04,ch_mask=0xF,fc_mask=0x07/).
        /bin/dmesg | grep -i perf may provide additional information.
      
        Program received signal SIGSEGV, Segmentation fault.
        0x00005555559b03ea in perf_evsel__close_fd_cpu (evsel=0x5555560951a0, cpu=1) at evsel.c:166
        166                     if (FD(evsel, cpu, thread) >= 0)
      
      v3. fixes a bug in perf_evsel__run_ioctl where the sense of a branch was
          backward.
      Signed-off-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/20210918054440.2350466-1-irogers@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      aba5daeb