1. 29 11月, 2022 2 次提交
    • J
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 4f4a5de1
      Jakub Kicinski 提交于
      Daniel Borkmann says:
      
      ====================
      bpf 2022-11-25
      
      We've added 10 non-merge commits during the last 8 day(s) which contain
      a total of 7 files changed, 48 insertions(+), 30 deletions(-).
      
      The main changes are:
      
      1) Several libbpf ringbuf fixes related to probing for its availability,
         size overflows when mmaping a 2G ringbuf and rejection of invalid
         reservationsizes, from Hou Tao.
      
      2) Fix a buggy return pointer in libbpf for attach_raw_tp function,
         from Jiri Olsa.
      
      3) Fix a local storage BPF map bug where the value's spin lock field
         can get initialized incorrectly, from Xu Kuohai.
      
      4) Two follow-up fixes in kprobe_multi BPF selftests for BPF CI,
         from Jiri Olsa.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        selftests/bpf: Make test_bench_attach serial
        selftests/bpf: Filter out default_idle from kprobe_multi bench
        bpf: Set and check spin lock value in sk_storage_map_test
        bpf: Do not copy spin lock field from user in bpf_selem_alloc
        libbpf: Check the validity of size in user_ring_buffer__reserve()
        libbpf: Handle size overflow for user ringbuf mmap
        libbpf: Handle size overflow for ringbuf mmap
        libbpf: Use page size as max_entries when probing ring buffer map
        bpf, perf: Use subprog name when reporting subprog ksymbol
        libbpf: Use correct return pointer in attach_raw_tp
      ====================
      
      Link: https://lore.kernel.org/r/20221125001034.29473-1-daniel@iogearbox.netSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      4f4a5de1
    • I
      ipv4: Fix route deletion when nexthop info is not specified · d5082d38
      Ido Schimmel 提交于
      When the kernel receives a route deletion request from user space it
      tries to delete a route that matches the route attributes specified in
      the request.
      
      If only prefix information is specified in the request, the kernel
      should delete the first matching FIB alias regardless of its associated
      FIB info. However, an error is currently returned when the FIB info is
      backed by a nexthop object:
      
       # ip nexthop add id 1 via 192.0.2.2 dev dummy10
       # ip route add 198.51.100.0/24 nhid 1
       # ip route del 198.51.100.0/24
       RTNETLINK answers: No such process
      
      Fix by matching on such a FIB info when legacy nexthop attributes are
      not specified in the request. An earlier check already covers the case
      where a nexthop ID is specified in the request.
      
      Add tests that cover these flows. Before the fix:
      
       # ./fib_nexthops.sh -t ipv4_fcnal
       ...
       TEST: Delete route when not specifying nexthop attributes           [FAIL]
      
       Tests passed:  11
       Tests failed:   1
      
      After the fix:
      
       # ./fib_nexthops.sh -t ipv4_fcnal
       ...
       TEST: Delete route when not specifying nexthop attributes           [ OK ]
      
       Tests passed:  12
       Tests failed:   0
      
      No regressions in other tests:
      
       # ./fib_nexthops.sh
       ...
       Tests passed: 228
       Tests failed:   0
      
       # ./fib_tests.sh
       ...
       Tests passed: 186
       Tests failed:   0
      
      Cc: stable@vger.kernel.org
      Reported-by: NJonas Gorski <jonas.gorski@gmail.com>
      Tested-by: NJonas Gorski <jonas.gorski@gmail.com>
      Fixes: 493ced1a ("ipv4: Allow routes to use nexthop objects")
      Fixes: 6bf92d70 ("net: ipv4: fix route with nexthop object delete warning")
      Fixes: 61b91eb3 ("ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference")
      Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: NNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: NDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20221124210932.2470010-1-idosch@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      d5082d38
  2. 28 11月, 2022 13 次提交
  3. 25 11月, 2022 8 次提交
  4. 24 11月, 2022 17 次提交