1. 24 3月, 2020 3 次提交
  2. 21 3月, 2020 1 次提交
  3. 20 3月, 2020 6 次提交
    • Y
      bpf, tcp: Make tcp_bpf_recvmsg static · c0fd336e
      YueHaibing 提交于
      After commit f747632b ("bpf: sockmap: Move generic sockmap
      hooks from BPF TCP"), tcp_bpf_recvmsg() is not used out of
      tcp_bpf.c, so make it static and remove it from tcp.h. Also move
      it to BPF_STREAM_PARSER #ifdef to fix unused function warnings.
      
      Fixes: f747632b ("bpf: sockmap: Move generic sockmap hooks from BPF TCP")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200320023426.60684-3-yuehaibing@huawei.com
      c0fd336e
    • Y
      bpf, tcp: Fix unused function warnings · a2652798
      YueHaibing 提交于
      If BPF_STREAM_PARSER is not set, gcc warns:
      
        net/ipv4/tcp_bpf.c:483:12: warning: 'tcp_bpf_sendpage' defined but not used [-Wunused-function]
        net/ipv4/tcp_bpf.c:395:12: warning: 'tcp_bpf_sendmsg' defined but not used [-Wunused-function]
        net/ipv4/tcp_bpf.c:13:13: warning: 'tcp_bpf_stream_read' defined but not used [-Wunused-function]
      
      Moves the unused functions into the #ifdef CONFIG_BPF_STREAM_PARSER.
      
      Fixes: f747632b ("bpf: sockmap: Move generic sockmap hooks from BPF TCP")
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: NLorenz Bauer <lmb@cloudflare.com>
      Reviewed-by: NJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200320023426.60684-2-yuehaibing@huawei.com
      a2652798
    • M
      bpftool: Add struct_ops support · 65c93628
      Martin KaFai Lau 提交于
      This patch adds struct_ops support to the bpftool.
      
      To recap a bit on the recent bpf_struct_ops feature on the kernel side:
      It currently supports "struct tcp_congestion_ops" to be implemented
      in bpf.  At a high level, bpf_struct_ops is struct_ops map populated
      with a number of bpf progs.  bpf_struct_ops currently supports the
      "struct tcp_congestion_ops".  However, the bpf_struct_ops design is
      generic enough that other kernel struct ops can be supported in
      the future.
      
      Although struct_ops is map+progs at a high lever, there are differences
      in details.  For example,
      1) After registering a struct_ops, the struct_ops is held by the kernel
         subsystem (e.g. tcp-cc).  Thus, there is no need to pin a
         struct_ops map or its progs in order to keep them around.
      2) To iterate all struct_ops in a system, it iterates all maps
         in type BPF_MAP_TYPE_STRUCT_OPS.  BPF_MAP_TYPE_STRUCT_OPS is
         the current usual filter.  In the future, it may need to
         filter by other struct_ops specific properties.  e.g. filter by
         tcp_congestion_ops or other kernel subsystem ops in the future.
      3) struct_ops requires the running kernel having BTF info.  That allows
         more flexibility in handling other kernel structs.  e.g. it can
         always dump the latest bpf_map_info.
      4) Also, "struct_ops" command is not intended to repeat all features
         already provided by "map" or "prog".  For example, if there really
         is a need to pin the struct_ops map, the user can use the "map" cmd
         to do that.
      
      While the first attempt was to reuse parts from map/prog.c,  it ended up
      not a lot to share.  The only obvious item is the map_parse_fds() but
      that still requires modifications to accommodate struct_ops map specific
      filtering (for the immediate and the future needs).  Together with the
      earlier mentioned differences, it is better to part away from map/prog.c.
      
      The initial set of subcmds are, register, unregister, show, and dump.
      
      For register, it registers all struct_ops maps that can be found in an
      obj file.  Option can be added in the future to specify a particular
      struct_ops map.  Also, the common bpf_tcp_cc is stateless (e.g.
      bpf_cubic.c and bpf_dctcp.c).  The "reuse map" feature is not
      implemented in this patch and it can be considered later also.
      
      For other subcmds, please see the man doc for details.
      
      A sample output of dump:
      [root@arch-fb-vm1 bpf]# bpftool struct_ops dump name cubic
      [{
              "bpf_map_info": {
                  "type": 26,
                  "id": 64,
                  "key_size": 4,
                  "value_size": 256,
                  "max_entries": 1,
                  "map_flags": 0,
                  "name": "cubic",
                  "ifindex": 0,
                  "btf_vmlinux_value_type_id": 18452,
                  "netns_dev": 0,
                  "netns_ino": 0,
                  "btf_id": 52,
                  "btf_key_type_id": 0,
                  "btf_value_type_id": 0
              }
          },{
              "bpf_struct_ops_tcp_congestion_ops": {
                  "refcnt": {
                      "refs": {
                          "counter": 1
                      }
                  },
                  "state": "BPF_STRUCT_OPS_STATE_INUSE",
                  "data": {
                      "list": {
                          "next": 0,
                          "prev": 0
                      },
                      "key": 0,
                      "flags": 0,
                      "init": "void (struct sock *) bictcp_init/prog_id:138",
                      "release": "void (struct sock *) 0",
                      "ssthresh": "u32 (struct sock *) bictcp_recalc_ssthresh/prog_id:141",
                      "cong_avoid": "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140",
                      "set_state": "void (struct sock *, u8) bictcp_state/prog_id:142",
                      "cwnd_event": "void (struct sock *, enum tcp_ca_event) bictcp_cwnd_event/prog_id:139",
                      "in_ack_event": "void (struct sock *, u32) 0",
                      "undo_cwnd": "u32 (struct sock *) tcp_reno_undo_cwnd/prog_id:144",
                      "pkts_acked": "void (struct sock *, const struct ack_sample *) bictcp_acked/prog_id:143",
                      "min_tso_segs": "u32 (struct sock *) 0",
                      "sndbuf_expand": "u32 (struct sock *) 0",
                      "cong_control": "void (struct sock *, const struct rate_sample *) 0",
                      "get_info": "size_t (struct sock *, u32, int *, union tcp_cc_info *) 0",
                      "name": "bpf_cubic",
                      "owner": 0
                  }
              }
          }
      ]
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200318171656.129650-1-kafai@fb.com
      65c93628
    • M
      bpftool: Translate prog_id to its bpf prog_name · d5ae04da
      Martin KaFai Lau 提交于
      The kernel struct_ops obj has kernel's func ptrs implemented by bpf_progs.
      The bpf prog_id is stored as the value of the func ptr for introspection
      purpose.  In the latter patch, a struct_ops dump subcmd will be added
      to introspect these func ptrs.  It is desired to print the actual bpf
      prog_name instead of only printing the prog_id.
      
      Since struct_ops is the only usecase storing prog_id in the func ptr,
      this patch adds a prog_id_as_func_ptr bool (default is false) to
      "struct btf_dumper" in order not to mis-interpret the ptr value
      for the other existing use-cases.
      
      While printing a func_ptr as a bpf prog_name,
      this patch also prefix the bpf prog_name with the ptr's func_proto.
      [ Note that it is the ptr's func_proto instead of the bpf prog's
        func_proto ]
      It reuses the current btf_dump_func() to obtain the ptr's func_proto
      string.
      
      Here is an example from the bpf_cubic.c:
      "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140"
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200318171650.129252-1-kafai@fb.com
      d5ae04da
    • M
      bpftool: Print as a string for char array · 30255d31
      Martin KaFai Lau 提交于
      A char[] is currently printed as an integer array.
      This patch will print it as a string when
      1) The array element type is an one byte int
      2) The array element type has a BTF_INT_CHAR encoding or
         the array element type's name is "char"
      3) All characters is between (0x1f, 0x7f) and it is terminated
         by a null character.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200318171643.129021-1-kafai@fb.com
      30255d31
    • M
      bpftool: Print the enum's name instead of value · ca7e6e45
      Martin KaFai Lau 提交于
      This patch prints the enum's name if there is one found in
      the array of btf_enum.
      
      The commit 9eea9849 ("bpf: fix BTF verification of enums")
      has details about an enum could have any power-of-2 size (up to 8 bytes).
      This patch also takes this chance to accommodate these non 4 byte
      enums.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200318171637.128862-1-kafai@fb.com
      ca7e6e45
  4. 19 3月, 2020 1 次提交
  5. 18 3月, 2020 6 次提交
  6. 17 3月, 2020 4 次提交
    • J
      sfc: fix XDP-redirect in this driver · 86e85bf6
      Jesper Dangaard Brouer 提交于
      XDP-redirect is broken in this driver sfc. XDP_REDIRECT requires
      tailroom for skb_shared_info when creating an SKB based on the
      redirected xdp_frame (both in cpumap and veth).
      
      The fix requires some initial explaining. The driver uses RX page-split
      when possible. It reserves the top 64 bytes in the RX-page for storing
      dma_addr (struct efx_rx_page_state). It also have the XDP recommended
      headroom of XDP_PACKET_HEADROOM (256 bytes). As it doesn't reserve any
      tailroom, it can still fit two standard MTU (1500) frames into one page.
      
      The sizeof struct skb_shared_info in 320 bytes. Thus drivers like ixgbe
      and i40e, reduce their XDP headroom to 192 bytes, which allows them to
      fit two frames with max 1536 bytes into a 4K page (192+1536+320=2048).
      
      The fix is to reduce this drivers headroom to 128 bytes and add the 320
      bytes tailroom. This account for reserved top 64 bytes in the page, and
      still fit two frame in a page for normal MTUs.
      
      We must never go below 128 bytes of headroom for XDP, as one cacheline
      is for xdp_frame area and next cacheline is reserved for metadata area.
      
      Fixes: eb9a36be ("sfc: perform XDP processing on received packets")
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86e85bf6
    • A
      remoteproc: clean up notification config · 5e0ef51b
      Alex Elder 提交于
      Rearrange the config files for remoteproc and IPA to fix their
      interdependencies.
      
      First, have CONFIG_QCOM_Q6V5_MSS select QCOM_Q6V5_IPA_NOTIFY so the
      notification code is built regardless of whether IPA needs it.
      
      Next, represent QCOM_IPA as being dependent on QCOM_Q6V5_MSS rather
      than setting its value to match QCOM_Q6V5_COMMON (which is selected
      by QCOM_Q6V5_MSS).
      
      Drop all dependencies from QCOM_Q6V5_IPA_NOTIFY.  The notification
      code will be built whenever QCOM_Q6V5_MSS is set, and it has no other
      dependencies.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e0ef51b
    • M
      net: kcm: kcmproc.c: Fix RCU list suspicious usage warning · 1963507e
      Madhuparna Bhowmik 提交于
      This path fixes the suspicious RCU usage warning reported by
      kernel test robot.
      
      net/kcm/kcmproc.c:#RCU-list_traversed_in_non-reader_section
      
      There is no need to use list_for_each_entry_rcu() in
      kcm_stats_seq_show() as the list is always traversed under
      knet->mutex held.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1963507e
    • Z
      qede: remove some unused code in function qede_selftest_receive_traffic · 10ee4b87
      Zheng Zengkai 提交于
      Remove set but not used variables 'sw_comp_cons' and 'hw_comp_cons'
      to fix gcc '-Wunused-but-set-variable' warning:
      
      drivers/net/ethernet/qlogic/qede/qede_ethtool.c: In function qede_selftest_receive_traffic:
      drivers/net/ethernet/qlogic/qede/qede_ethtool.c:1569:20:
       warning: variable sw_comp_cons set but not used [-Wunused-but-set-variable]
      drivers/net/ethernet/qlogic/qede/qede_ethtool.c: In function qede_selftest_receive_traffic:
      drivers/net/ethernet/qlogic/qede/qede_ethtool.c:1569:6:
       warning: variable hw_comp_cons set but not used [-Wunused-but-set-variable]
      
      After removing 'hw_comp_cons',the memory barrier 'rmb()' and its comments become useless,
      so remove them as well.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10ee4b87
  7. 16 3月, 2020 19 次提交