1. 26 Jan, 2019 6 commits
    • Florian Fainelli's avatar
      perf tests ARM: Disable breakpoint tests 32-bit · 389cde57
      Florian Fainelli authored
      [ Upstream commit 24f96733 ]
      
      The breakpoint tests on the ARM 32-bit kernel are broken in several
      ways.
      
      The breakpoint length requested does not necessarily match whether the
      function address has the Thumb bit (bit 0) set or not, and this does
      matter to the ARM kernel hw_breakpoint infrastructure. See [1] for
      background.
      
      [1]: https://lkml.org/lkml/2018/11/15/205
      
      As Will indicated, the overflow handling would require single-stepping
      which is not supported at the moment. Just disable those tests for the
      ARM 32-bit platforms and update the comment above to explain these
      limitations.
      Co-developed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: Jiri Olsa's avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20181203191138.2419-1-f.fainelli@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      389cde57
    • Adrian Hunter's avatar
      perf intel-pt: Fix error with config term "pt=0" · 7eb6443f
      Adrian Hunter authored
      [ Upstream commit 1c6f709b ]
      
      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: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/b7c5b4e5-9497-10e5-fd43-5f3e4a0fe51d@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7eb6443f
    • Adrian Hunter's avatar
      tools lib traceevent: Fix compile warnings in tools/lib/traceevent/event-parse.c · 7dd70b09
      Adrian Hunter authored
      [ Upstream commit 0631ca3a ]
      
      Fix following warnings:
      
        event-parse.c: In function ‘tep_find_event_by_name’:
        event-parse.c:3521:21: warning: ‘event’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          pevent->last_event = event;
          ~~~~~~~~~~~~~~~~~~~^~~~~~~
          CC       ui/gtk/hists.o
          LINK     plugin_mac80211.so
          CC       nlattr.o
        event-parse.c: In function ‘tep_data_lat_fmt’:
        event-parse.c:5200:4: warning: ‘migrate_disable’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", migrate_disable);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:5207:4: warning: ‘lock_depth’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", lock_depth);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          LINK     plugin_sched_switch.so
          LINK     plugin_function.so
          LINK     plugin_xen.so
        event-parse.c: In function ‘tep_event_info’:
        event-parse.c:5047:7: warning: ‘len_arg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
               trace_seq_printf(s, format, len_arg, (char)val);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4884:6: note: ‘len_arg’ was declared here
          int len_arg;
              ^~~~~~~
        event-parse.c:4338:11: warning: ‘vsize’ may be used uninitialized in this function [-Wmaybe-uninitialized]
             val = tep_read_number(pevent, bptr, vsize);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4224:6: note: ‘vsize’ was declared here
          int vsize;
              ^~~~~
      
      $ gcc --version
        gcc (Clear Linux OS for Intel Architecture) 8.2.1 20180502
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
      Link: http://lkml.kernel.org/r/20181122112937.10582-1-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7dd70b09
    • Jiong Wang's avatar
      bpf: relax verifier restriction on BPF_MOV | BPF_ALU · 525cd39f
      Jiong Wang authored
      [ Upstream commit e434b8cd ]
      
      Currently, the destination register is marked as unknown for 32-bit
      sub-register move (BPF_MOV | BPF_ALU) whenever the source register type is
      SCALAR_VALUE.
      
      This is too conservative that some valid cases will be rejected.
      Especially, this may turn a constant scalar value into unknown value that
      could break some assumptions of verifier.
      
      For example, test_l4lb_noinline.c has the following C code:
      
          struct real_definition *dst
      
      1:  if (!get_packet_dst(&dst, &pckt, vip_info, is_ipv6))
      2:    return TC_ACT_SHOT;
      3:
      4:  if (dst->flags & F_IPV6) {
      
      get_packet_dst is responsible for initializing "dst" into valid pointer and
      return true (1), otherwise return false (0). The compiled instruction
      sequence using alu32 will be:
      
        412: (54) (u32) r7 &= (u32) 1
        413: (bc) (u32) r0 = (u32) r7
        414: (95) exit
      
      insn 413, a BPF_MOV | BPF_ALU, however will turn r0 into unknown value even
      r7 contains SCALAR_VALUE 1.
      
      This causes trouble when verifier is walking the code path that hasn't
      initialized "dst" inside get_packet_dst, for which case 0 is returned and
      we would then expect verifier concluding line 1 in the above C code pass
      the "if" check, therefore would skip fall through path starting at line 4.
      Now, because r0 returned from callee has became unknown value, so verifier
      won't skip analyzing path starting at line 4 and "dst->flags" requires
      dereferencing the pointer "dst" which actually hasn't be initialized for
      this path.
      
      This patch relaxed the code marking sub-register move destination. For a
      SCALAR_VALUE, it is safe to just copy the value from source then truncate
      it into 32-bit.
      
      A unit test also included to demonstrate this issue. This test will fail
      before this patch.
      
      This relaxation could let verifier skipping more paths for conditional
      comparison against immediate. It also let verifier recording a more
      accurate/strict value for one register at one state, if this state end up
      with going through exit without rejection and it is used for state
      comparison later, then it is possible an inaccurate/permissive value is
      better. So the real impact on verifier processed insn number is complex.
      But in all, without this fix, valid program could be rejected.
      
      >From real benchmarking on kernel selftests and Cilium bpf tests, there is
      no impact on processed instruction number when tests ares compiled with
      default compilation options. There is slightly improvements when they are
      compiled with -mattr=+alu32 after this patch.
      
      Also, test_xdp_noinline/-mattr=+alu32 now passed verification. It is
      rejected before this fix.
      
      Insn processed before/after this patch:
      
                              default     -mattr=+alu32
      
      Kernel selftest
      
      ===
      test_xdp.o              371/371      369/369
      test_l4lb.o             6345/6345    5623/5623
      test_xdp_noinline.o     2971/2971    rejected/2727
      test_tcp_estates.o      429/429      430/430
      
      Cilium bpf
      ===
      bpf_lb-DLB_L3.o:        2085/2085     1685/1687
      bpf_lb-DLB_L4.o:        2287/2287     1986/1982
      bpf_lb-DUNKNOWN.o:      690/690       622/622
      bpf_lxc.o:              95033/95033   N/A
      bpf_netdev.o:           7245/7245     N/A
      bpf_overlay.o:          2898/2898     3085/2947
      
      NOTE:
        - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by
          verifier due to another issue inside verifier on supporting alu32
          binary.
        - Each cilium bpf program could generate several processed insn number,
          above number is sum of them.
      
      v1->v2:
       - Restrict the change on SCALAR_VALUE.
       - Update benchmark numbers on Cilium bpf tests.
      Signed-off-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      525cd39f
    • Dmitry V. Levin's avatar
      selftests: do not macro-expand failed assertion expressions · 3fef5905
      Dmitry V. Levin authored
      [ Upstream commit b708a3cc ]
      
      I've stumbled over the current macro-expand behaviour of the test
      harness:
      
      $ gcc -Wall -xc - <<'__EOF__'
      TEST(macro) {
      	int status = 0;
      	ASSERT_TRUE(WIFSIGNALED(status));
      }
      TEST_HARNESS_MAIN
      __EOF__
      $ ./a.out
      [==========] Running 1 tests from 1 test cases.
      [ RUN      ] global.macro
      <stdin>: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
      <stdin>: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 <shuah@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-kselftest@vger.kernel.org
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3fef5905
    • Quentin Monnet's avatar
      selftests/bpf: enable (uncomment) all tests in test_libbpf.sh · 8662b900
      Quentin Monnet authored
      [ Upstream commit f96afa76 ]
      
      libbpf is now able to load successfully test_l4lb_noinline.o and
      samples/bpf/tracex3_kern.o.
      
      For the test_l4lb_noinline, uncomment related tests from test_libbpf.c
      and remove the associated "TODO".
      
      For tracex3_kern.o, instead of loading a program from samples/bpf/ that
      might not have been compiled at this stage, try loading a program from
      BPF selftests. Since this test case is about loading a program compiled
      without the "-target bpf" flag, change the Makefile to compile one
      program accordingly (instead of passing the flag for compiling all
      programs).
      
      Regarding test_xdp_noinline.o: in its current shape the program fails to
      load because it provides no version section, but the loader needs one.
      The test was added to make sure that libbpf could load XDP programs even
      if they do not provide a version number in a dedicated section. But
      libbpf is already capable of doing that: in our case loading fails
      because the loader does not know that this is an XDP program (it does
      not need to, since it does not attach the program). So trying to load
      test_xdp_noinline.o does not bring much here: just delete this subtest.
      
      For the record, the error message obtained with tracex3_kern.o was
      fixed by commit e3d91b0c ("tools/libbpf: handle issues with bpf ELF
      objects containing .eh_frames")
      
      I have not been abled to reproduce the "libbpf: incorrect bpf_call
      opcode" error for test_l4lb_noinline.o, even with the version of libbpf
      present at the time when test_libbpf.sh and test_libbpf_open.c were
      created.
      
      RFC -> v1:
      - Compile test_xdp without the "-target bpf" flag, and try to load it
        instead of ../../samples/bpf/tracex3_kern.o.
      - Delete test_xdp_noinline.o subtest.
      
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: Quentin Monnet's avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8662b900
  2. 13 Jan, 2019 3 commits
    • Shuah Khan's avatar
      selftests: Fix test errors related to lib.mk khdr target · a05257f9
      Shuah Khan authored
      commit 211929fd upstream.
      
      Commit b2d35fa5 ("selftests: add headers_install to lib.mk") added
      khdr target to run headers_install target from the main Makefile. The
      logic uses KSFT_KHDR_INSTALL and top_srcdir as controls to initialize
      variables and include files to run headers_install from the top level
      Makefile. There are a few problems with this logic.
      
      1. Exposes top_srcdir to all tests
      2. Common logic impacts all tests
      3. Uses KSFT_KHDR_INSTALL, top_srcdir, and khdr in an adhoc way. Tests
         add "khdr" dependency in their Makefiles to TEST_PROGS_EXTENDED in
         some cases, and STATIC_LIBS in other cases. This makes this framework
         confusing to use.
      
      The common logic that runs for all tests even when KSFT_KHDR_INSTALL
      isn't defined by the test. top_srcdir is initialized to a default value
      when test doesn't initialize it. It works for all tests without a sub-dir
      structure and tests with sub-dir structure fail to build.
      
      e.g: make -C sparc64/drivers/ or make -C drivers/dma-buf
      
      ../../lib.mk:20: ../../../../scripts/subarch.include: No such file or directory
      make: *** No rule to make target '../../../../scripts/subarch.include'.  Stop.
      
      There is no reason to require all tests to define top_srcdir and there is
      no need to require tests to add khdr dependency using adhoc changes to
      TEST_* and other variables.
      
      Fix it with a consistent use of KSFT_KHDR_INSTALL and top_srcdir from tests
      that have the dependency on headers_install.
      
      Change common logic to include khdr target define and "all" target with
      dependency on khdr when KSFT_KHDR_INSTALL is defined.
      
      Only tests that have dependency on headers_install have to define just
      the KSFT_KHDR_INSTALL, and top_srcdir variables and there is no need to
      specify khdr dependency in the test Makefiles.
      
      Fixes: b2d35fa5 ("selftests: add headers_install to lib.mk")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a05257f9
    • Dan Williams's avatar
      mm, devm_memremap_pages: fix shutdown handling · 6e6a8b24
      Dan Williams authored
      commit a95c90f1 upstream.
      
      The last step before devm_memremap_pages() returns success is to allocate
      a release action, devm_memremap_pages_release(), to tear the entire setup
      down.  However, the result from devm_add_action() is not checked.
      
      Checking the error from devm_add_action() is not enough.  The api
      currently relies on the fact that the percpu_ref it is using is killed by
      the time the devm_memremap_pages_release() is run.  Rather than continue
      this awkward situation, offload the responsibility of killing the
      percpu_ref to devm_memremap_pages_release() directly.  This allows
      devm_memremap_pages() to do the right thing relative to init failures and
      shutdown.
      
      Without this change we could fail to register the teardown of
      devm_memremap_pages().  The likelihood of hitting this failure is tiny as
      small memory allocations almost always succeed.  However, the impact of
      the failure is large given any future reconfiguration, or disable/enable,
      of an nvdimm namespace will fail forever as subsequent calls to
      devm_memremap_pages() will fail to setup the pgmap_radix since there will
      be stale entries for the physical address range.
      
      An argument could be made to require that the ->kill() operation be set in
      the @pgmap arg rather than passed in separately.  However, it helps code
      readability, tracking the lifetime of a given instance, to be able to grep
      the kill routine directly at the devm_memremap_pages() call site.
      
      Link: http://lkml.kernel.org/r/154275558526.76910.7535251937849268605.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Fixes: e8d51348 ("memremap: change devm_memremap_pages interface...")
      Reviewed-by: default avatar"Jérôme Glisse" <jglisse@redhat.com>
      Reported-by: Logan Gunthorpe's avatarLogan Gunthorpe <logang@deltatee.com>
      Reviewed-by: Logan Gunthorpe's avatarLogan Gunthorpe <logang@deltatee.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Balbir Singh <bsingharora@gmail.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e6a8b24
    • Dan Williams's avatar
      mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL · 6765d93c
      Dan Williams authored
      commit 808153e1 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.comSigned-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: Balbir Singh <bsingharora@gmail.com>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6765d93c
  3. 09 Jan, 2019 7 commits
  4. 19 Dec, 2018 2 commits
  5. 14 Dec, 2018 1 commit
  6. 13 Dec, 2018 1 commit
    • Jakub Kicinski's avatar
      bpf: verifier: make sure callees don't prune with caller differences · 7640ead9
      Jakub Kicinski authored
      Currently for liveness and state pruning the register parentage
      chains don't include states of the callee.  This makes some sense
      as the callee can't access those registers.  However, this means
      that READs done after the callee returns will not propagate into
      the states of the callee.  Callee will then perform pruning
      disregarding differences in caller state.
      
      Example:
      
         0: (85) call bpf_user_rnd_u32
         1: (b7) r8 = 0
         2: (55) if r0 != 0x0 goto pc+1
         3: (b7) r8 = 1
         4: (bf) r1 = r8
         5: (85) call pc+4
         6: (15) if r8 == 0x1 goto pc+1
         7: (05) *(u64 *)(r9 - 8) = r3
         8: (b7) r0 = 0
         9: (95) exit
      
         10: (15) if r1 == 0x0 goto pc+0
         11: (95) exit
      
      Here we acquire unknown state with call to get_random() [1].  Then
      we store this random state in r8 (either 0 or 1) [1 - 3], and make
      a call on line 5.  Callee does nothing but a trivial conditional
      jump (to create a pruning point).  Upon return caller checks the
      state of r8 and either performs an unsafe read or not.
      
      Verifier will first explore the path with r8 == 1, creating a pruning
      point at [11].  The parentage chain for r8 will include only callers
      states so once verifier reaches [6] it will mark liveness only on states
      in the caller, and not [11].  Now when verifier walks the paths with
      r8 == 0 it will reach [11] and since REG_LIVE_READ on r8 was not
      propagated there it will prune the walk entirely (stop walking
      the entire program, not just the callee).  Since [6] was never walked
      with r8 == 0, [7] will be considered dead and replaced with "goto -1"
      causing hang at runtime.
      
      This patch weaves the callee's explored states onto the callers
      parentage chain.  Rough parentage for r8 would have looked like this
      before:
      
      [0] [1] [2] [3] [4] [5]   [10]      [11]      [6]      [7]
           |           |      ,---|----.    |        |        |
        sl0:         sl0:    / sl0:     \ sl0:      sl0:     sl0:
        fr0: r8 <-- fr0: r8<+--fr0: r8   `fr0: r8  ,fr0: r8<-fr0: r8
                             \ fr1: r8 <- fr1: r8 /
                              \__________________/
      
      after:
      
      [0] [1] [2] [3] [4] [5]   [10]      [11]      [6]      [7]
           |           |          |         |        |        |
         sl0:         sl0:      sl0:       sl0:      sl0:     sl0:
         fr0: r8 <-- fr0: r8 <- fr0: r8 <- fr0: r8 <-fr0: r8<-fr0: r8
                                fr1: r8 <- fr1: r8
      
      Now the mark from instruction 6 will travel through callees states.
      
      Note that we don't have to connect r0 because its overwritten by
      callees state on return and r1 - r5 because those are not alive
      any more once a call is made.
      
      v2:
       - don't connect the callees registers twice (Alexei: suggestion & code)
       - add more details to the comment (Ed & Alexei)
      v1: don't unnecessarily link caller saved regs (Jiong)
      
      Fixes: f4d7e40a ("bpf: introduce function calls (verification)")
      Reported-by: David Beckett's avatarDavid Beckett <david.beckett@netronome.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Reviewed-by: Edward Cree's avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      7640ead9
  7. 12 Dec, 2018 1 commit
  8. 11 Dec, 2018 1 commit
  9. 10 Dec, 2018 1 commit
  10. 07 Dec, 2018 1 commit
  11. 06 Dec, 2018 1 commit
    • Matthew Wilcox's avatar
      radix tree: Don't return retry entries from lookup · eff3860b
      Matthew Wilcox authored
      Commit 66ee620f ("idr: Permit any valid kernel pointer to be stored")
      changed the radix tree lookup so that it stops when reaching the bottom
      of the tree.  However, the condition was added in the wrong place,
      making it possible to return retry entries to the caller.  Reorder the
      tests to check for the retry entry before checking whether we're at the
      bottom of the tree.  The retry entry should never be found in the tree
      root, so it's safe to defer the check until the end of the loop.
      
      Add a regression test to the test-suite to be sure this doesn't come
      back.
      
      Fixes: 66ee620f ("idr: Permit any valid kernel pointer to be stored")
      Reported-by: Greg Kurz's avatarGreg Kurz <groug@kaod.org>
      Signed-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      eff3860b
  12. 05 Dec, 2018 1 commit
  13. 04 Dec, 2018 1 commit
    • Alexei Starovoitov's avatar
      bpf: improve verifier branch analysis · 4f7b3e82
      Alexei Starovoitov authored
      pathological bpf programs may try to force verifier to explode in
      the number of branch states:
        20: (d5) if r1 s<= 0x24000028 goto pc+0
        21: (b5) if r0 <= 0xe1fa20 goto pc+2
        22: (d5) if r1 s<= 0x7e goto pc+0
        23: (b5) if r0 <= 0xe880e000 goto pc+0
        24: (c5) if r0 s< 0x2100ecf4 goto pc+0
        25: (d5) if r1 s<= 0xe880e000 goto pc+1
        26: (c5) if r0 s< 0xf4041810 goto pc+0
        27: (d5) if r1 s<= 0x1e007e goto pc+0
        28: (b5) if r0 <= 0xe86be000 goto pc+0
        29: (07) r0 += 16614
        30: (c5) if r0 s< 0x6d0020da goto pc+0
        31: (35) if r0 >= 0x2100ecf4 goto pc+0
      
      Teach verifier to recognize always taken and always not taken branches.
      This analysis is already done for == and != comparison.
      Expand it to all other branches.
      
      It also helps real bpf programs to be verified faster:
                             before  after
      bpf_lb-DLB_L3.o         2003    1940
      bpf_lb-DLB_L4.o         3173    3089
      bpf_lb-DUNKNOWN.o       1080    1065
      bpf_lxc-DDROP_ALL.o     29584   28052
      bpf_lxc-DUNKNOWN.o      36916   35487
      bpf_netdev.o            11188   10864
      bpf_overlay.o           6679    6643
      bpf_lcx_jit.o           39555   38437
      Reported-by: default avatarAnatoly Trosinenko <anatoly.trosinenko@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: Edward Cree's avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      4f7b3e82
  14. 01 Dec, 2018 3 commits
  15. 30 Nov, 2018 2 commits
  16. 29 Nov, 2018 3 commits
    • Yonghong Song's avatar
      tools: bpftool: fix a bitfield pretty print issue · 528bff0c
      Yonghong Song authored
      Commit b12d6ec0 ("bpf: btf: add btf print functionality")
      added btf pretty print functionality to bpftool.
      There is a problem though in printing a bitfield whose type
      has modifiers.
      
      For example, for a type like
        typedef int ___int;
        struct tmp_t {
                int a:3;
                ___int b:3;
        };
      Suppose we have a map
        struct bpf_map_def SEC("maps") tmpmap = {
                .type = BPF_MAP_TYPE_HASH,
                .key_size = sizeof(__u32),
                .value_size = sizeof(struct tmp_t),
                .max_entries = 1,
        };
      and the hash table is populated with one element with
      key 0 and value (.a = 1 and .b = 2).
      
      In BTF, the struct member "b" will have a type "typedef" which
      points to an int type. The current implementation does not
      pass the bit offset during transition from typedef to int type,
      hence incorrectly print the value as
        $ bpftool m d id 79
        [{
                "key": 0,
                "value": {
                    "a": 0x1,
                    "b": 0x1
                }
            }
        ]
      
      This patch fixed the issue by carrying bit_offset along the type
      chain during bit_field print. The correct result can be printed as
        $ bpftool m d id 76
        [{
                "key": 0,
                "value": {
                    "a": 0x1,
                    "b": 0x2
                }
            }
        ]
      
      The kernel pretty print is implemented correctly and does not
      have this issue.
      
      Fixes: b12d6ec0 ("bpf: btf: add btf print functionality")
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      528bff0c
    • Yonghong Song's avatar
      tools/bpf: add addition type tests to test_btf · d0848912
      Yonghong Song authored
      The following additional unit testcases are added to test_btf:
      ...
      BTF raw test[42] (typedef (invalid name, name_off = 0)): OK
      BTF raw test[43] (typedef (invalid name, invalid identifier)): OK
      BTF raw test[44] (ptr type (invalid name, name_off <> 0)): OK
      BTF raw test[45] (volatile type (invalid name, name_off <> 0)): OK
      BTF raw test[46] (const type (invalid name, name_off <> 0)): OK
      BTF raw test[47] (restrict type (invalid name, name_off <> 0)): OK
      BTF raw test[48] (fwd type (invalid name, name_off = 0)): OK
      BTF raw test[49] (fwd type (invalid name, invalid identifier)): OK
      BTF raw test[50] (array type (invalid name, name_off <> 0)): OK
      BTF raw test[51] (struct type (name_off = 0)): OK
      BTF raw test[52] (struct type (invalid name, invalid identifier)): OK
      BTF raw test[53] (struct member (name_off = 0)): OK
      BTF raw test[54] (struct member (invalid name, invalid identifier)): OK
      BTF raw test[55] (enum type (name_off = 0)): OK
      BTF raw test[56] (enum type (invalid name, invalid identifier)): OK
      BTF raw test[57] (enum member (invalid name, name_off = 0)): OK
      BTF raw test[58] (enum member (invalid name, invalid identifier)): OK
      ...
      
      Fixes: c0fa1b6c ("bpf: btf: Add BTF tests")
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d0848912
    • Martin KaFai Lau's avatar
      tools/bpf: fix two test_btf unit test cases · 8800cd03
      Martin KaFai Lau authored
      There are two unit test cases, which should encode
      TYPEDEF type, but instead encode PTR type.
      The error is flagged out after enforcing name
      checking in the previous patch.
      
      Fixes: c0fa1b6c ("bpf: btf: Add BTF tests")
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      8800cd03
  17. 28 Nov, 2018 1 commit
    • Thomas Gleixner's avatar
      x86/speculation: Add prctl() control for indirect branch speculation · 9137bb27
      Thomas Gleixner authored
      Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
      PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
      indirect branch speculation via STIBP and IBPB.
      
      Invocations:
       Check indirect branch speculation status with
       - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
      
       Enable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
      
       Disable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
      
       Force disable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
      
      See Documentation/userspace-api/spec_ctrl.rst.
      Signed-off-by: Tim Chen's avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
      9137bb27
  18. 21 Nov, 2018 1 commit
  19. 20 Nov, 2018 2 commits
  20. 19 Nov, 2018 1 commit