1. 27 Feb, 2019 10 commits
  2. 12 Feb, 2019 3 commits
  3. 06 Feb, 2019 1 commit
  4. 31 Jan, 2019 1 commit
    • Dave Hansen's avatar
      x86/selftests/pkeys: Fork() to check for state being preserved · 940343c7
      Dave Hansen authored
      commit e1812933 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
      Signed-off-by: 's avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      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 <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Joerg Roedel <jroedel@suse.de>
      Link: https://lkml.kernel.org/r/20190102215657.585704B7@viggo.jf.intel.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 26 Jan, 2019 3 commits
    • 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
      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;
      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
        - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by
          verifier due to another issue inside verifier on supporting alu32
        - Each cilium bpf program could generate several processed insn number,
          above number is sum of them.
       - Restrict the change on SCALAR_VALUE.
       - Update benchmark numbers on Cilium bpf tests.
      Signed-off-by: 's avatarJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
    • 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
      $ gcc -Wall -xc - <<'__EOF__'
      TEST(macro) {
      	int status = 0;
      $ ./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
      [==========] 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:
      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: 's avatarDmitry V. Levin <ldv@altlinux.org>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
    • 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
      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
      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
      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: 's avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: 's avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
  6. 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: 's avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • 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
      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: 's avatarDan Williams <dan.j.williams@intel.com>
      Fixes: e8d51348 ("memremap: change devm_memremap_pages interface...")
      Reviewed-by: 's 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: 's 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: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • 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: 's avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: 's avatarChristoph Hellwig <hch@lst.de>
      Acked-by: 's 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: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 19 Dec, 2018 1 commit
  8. 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.
         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
      [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 /
      [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.
       - 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: 's avatarDavid Beckett <david.beckett@netronome.com>
      Signed-off-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: 's avatarJiong Wang <jiong.wang@netronome.com>
      Reviewed-by: Edward Cree's avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
  9. 12 Dec, 2018 1 commit
  10. 11 Dec, 2018 1 commit
  11. 10 Dec, 2018 1 commit
  12. 07 Dec, 2018 1 commit
  13. 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
      Fixes: 66ee620f ("idr: Permit any valid kernel pointer to be stored")
      Reported-by: 's avatarGreg Kurz <groug@kaod.org>
      Signed-off-by: 's avatarMatthew Wilcox <willy@infradead.org>
  14. 05 Dec, 2018 1 commit
  15. 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: 's avatarAnatoly Trosinenko <anatoly.trosinenko@gmail.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: Edward Cree's avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
  16. 01 Dec, 2018 1 commit
    • Joe Stringer's avatar
      bpf: Support sk lookup in netns with id 0 · f71c6143
      Joe Stringer authored
      David Ahern and Nicolas Dichtel report that the handling of the netns id
      0 is incorrect for the BPF socket lookup helpers: rather than finding
      the netns with id 0, it is resolving to the current netns. This renders
      the netns_id 0 inaccessible.
      To fix this, adjust the API for the netns to treat all negative s32
      values as a lookup in the current netns (including u64 values which when
      truncated to s32 become negative), while any values with a positive
      value in the signed 32-bit integer space would result in a lookup for a
      socket in the netns corresponding to that id. As before, if the netns
      with that ID does not exist, no socket will be found. Any netns outside
      of these ranges will fail to find a corresponding socket, as those
      values are reserved for future usage.
      Signed-off-by: 's avatarJoe Stringer <joe@wand.net.nz>
      Acked-by: 's avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: Joey Pabalinas (jp)'s avatarJoey Pabalinas <joeypabalinas@gmail.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
  17. 30 Nov, 2018 2 commits
  18. 29 Nov, 2018 2 commits
    • 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: 's avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: 's avatarYonghong Song <yhs@fb.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
    • 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: 's avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: 's avatarYonghong Song <yhs@fb.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
  19. 18 Nov, 2018 2 commits
  20. 17 Nov, 2018 1 commit
  21. 15 Nov, 2018 1 commit
  22. 12 Nov, 2018 1 commit