1. 05 10月, 2020 5 次提交
  2. 04 10月, 2020 2 次提交
    • G
      net/sched: act_vlan: Add {POP,PUSH}_ETH actions · 19fbcb36
      Guillaume Nault 提交于
      Implement TCA_VLAN_ACT_POP_ETH and TCA_VLAN_ACT_PUSH_ETH, to
      respectively pop and push a base Ethernet header at the beginning of a
      frame.
      
      POP_ETH is just a matter of pulling ETH_HLEN bytes. VLAN tags, if any,
      must be stripped before calling POP_ETH.
      
      PUSH_ETH is restricted to skbs with no mac_header, and only the MAC
      addresses can be configured. The Ethertype is automatically set from
      skb->protocol. These restrictions ensure that all skb's fields remain
      consistent, so that this action can't confuse other part of the
      networking stack (like GSO).
      
      Since openvswitch already had these actions, consolidate the code in
      skbuff.c (like for vlan and mpls push/pop).
      Signed-off-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19fbcb36
    • J
      netlink: rework policy dump to support multiple policies · 04a351a6
      Johannes Berg 提交于
      Rework the policy dump code a bit to support adding multiple
      policies to a single dump, in order to e.g. support per-op
      policies in generic netlink.
      
      v2:
       - move kernel-doc to implementation [Jakub]
       - squash the first patch to not flip-flop on the prototype
         [Jakub]
       - merge netlink_policy_dump_get_policy_idx() with the old
         get_policy_idx() we already had
       - rebase without Jakub's patch to have per-op dump
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      04a351a6
  3. 03 10月, 2020 8 次提交
  4. 01 10月, 2020 6 次提交
  5. 30 9月, 2020 2 次提交
  6. 29 9月, 2020 3 次提交
  7. 28 9月, 2020 6 次提交
  8. 27 9月, 2020 4 次提交
  9. 26 9月, 2020 4 次提交
    • J
      devlink: introduce flash update overwrite mask · 5d5b4128
      Jacob Keller 提交于
      Sections of device flash may contain settings or device identifying
      information. When performing a flash update, it is generally expected
      that these settings and identifiers are not overwritten.
      
      However, it may sometimes be useful to allow overwriting these fields
      when performing a flash update. Some examples include, 1) customizing
      the initial device config on first programming, such as overwriting
      default device identifying information, or 2) reverting a device
      configuration to known good state provided in the new firmware image, or
      3) in case it is suspected that current firmware logic for managing the
      preservation of fields during an update is broken.
      
      Although some devices are able to completely separate these types of
      settings and fields into separate components, this is not true for all
      hardware.
      
      To support controlling this behavior, a new
      DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an
      nla_bitfield32 which will define what subset of fields in a component
      should be overwritten during an update.
      
      If no bits are specified, or of the overwrite mask is not provided, then
      an update should not overwrite anything, and should maintain the
      settings and identifiers as they are in the previous image.
      
      If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set,
      then the device should be configured to overwrite any of the settings in
      the requested component with settings found in the provided image.
      
      Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the
      device should be configured to overwrite any device identifiers in the
      requested component with the identifiers from the image.
      
      Multiple overwrite modes may be combined to indicate that a combination
      of the set of fields that should be overwritten.
      
      Drivers which support the new overwrite mask must set the
      DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the
      supported_flash_update_params field of their devlink_ops.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d5b4128
    • J
      devlink: convert flash_update to use params structure · bc75c054
      Jacob Keller 提交于
      The devlink core recently gained support for checking whether the driver
      supports a flash_update parameter, via `supported_flash_update_params`.
      However, parameters are specified as function arguments. Adding a new
      parameter still requires modifying the signature of the .flash_update
      callback in all drivers.
      
      Convert the .flash_update function to take a new `struct
      devlink_flash_update_params` instead. By using this structure, and the
      `supported_flash_update_params` bit field, a new parameter to
      flash_update can be added without requiring modification to existing
      drivers.
      
      As before, all parameters except file_name will require driver opt-in.
      Because file_name is a necessary field to for the flash_update to make
      sense, no "SUPPORTED" bitflag is provided and it is always considered
      valid. All future additional parameters will require a new bit in the
      supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc75c054
    • J
      devlink: check flash_update parameter support in net core · 22ec3d23
      Jacob Keller 提交于
      When implementing .flash_update, drivers which do not support
      per-component update are manually checking the component parameter to
      verify that it is NULL. Without this check, the driver might accept an
      update request with a component specified even though it will not honor
      such a request.
      
      Instead of having each driver check this, move the logic into
      net/core/devlink.c, and use a new `supported_flash_update_params` field
      in the devlink_ops. Drivers which will support per-component update must
      now specify this by setting DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT in
      the supported_flash_update_params in their devlink_ops.
      
      This helps ensure that drivers do not forget to check for a NULL
      component if they do not support per-component update. This also enables
      a slightly better error message by enabling the core stack to set the
      netlink bad attribute message to indicate precisely the unsupported
      attribute in the message.
      
      Going forward, any new additional parameter to flash update will require
      a bit in the supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Cc: Shannon Nelson <snelson@pensando.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22ec3d23
    • M
      bpf: Change bpf_sk_storage_*() to accept ARG_PTR_TO_BTF_ID_SOCK_COMMON · 592a3498
      Martin KaFai Lau 提交于
      This patch changes the bpf_sk_storage_*() to take
      ARG_PTR_TO_BTF_ID_SOCK_COMMON such that they will work with the pointer
      returned by the bpf_skc_to_*() helpers also.
      
      A micro benchmark has been done on a "cgroup_skb/egress" bpf program
      which does a bpf_sk_storage_get().  It was driven by netperf doing
      a 4096 connected UDP_STREAM test with 64bytes packet.
      The stats from "kernel.bpf_stats_enabled" shows no meaningful difference.
      
      The sk_storage_get_btf_proto, sk_storage_delete_btf_proto,
      btf_sk_storage_get_proto, and btf_sk_storage_delete_proto are
      no longer needed, so they are removed.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NLorenz Bauer <lmb@cloudflare.com>
      Link: https://lore.kernel.org/bpf/20200925000402.3856307-1-kafai@fb.com
      592a3498