1. 11 2月, 2019 1 次提交
  2. 09 2月, 2019 1 次提交
  3. 08 2月, 2019 7 次提交
  4. 06 2月, 2019 1 次提交
  5. 05 2月, 2019 1 次提交
  6. 04 2月, 2019 4 次提交
  7. 02 2月, 2019 6 次提交
    • J
      devlink: add version reporting to devlink info API · fc6fae7d
      Jakub Kicinski 提交于
      ethtool -i has a few fixed-size fields which can be used to report
      firmware version and expansion ROM version. Unfortunately, modern
      hardware has more firmware components. There is usually some
      datapath microcode, management controller, PXE drivers, and a
      CPLD load. Running ethtool -i on modern controllers reveals the
      fact that vendors cram multiple values into firmware version field.
      
      Here are some examples from systems I could lay my hands on quickly:
      
      tg3:  "FFV20.2.17 bc 5720-v1.39"
      i40e: "6.01 0x800034a4 1.1747.0"
      nfp:  "0.0.3.5 0.25 sriov-2.1.16 nic"
      
      Add a new devlink API to allow retrieving multiple versions, and
      provide user-readable name for those versions.
      
      While at it break down the versions into three categories:
       - fixed - this is the board/fixed component version, usually vendors
                 report information like the board version in the PCI VPD,
                 but it will benefit from naming and common API as well;
       - running - this is the running firmware version;
       - stored - this is firmware in the flash, after firmware update
                  this value will reflect the flashed version, while the
                  running version may only be updated after reboot.
      
      v3:
       - add per-type helpers instead of using the special argument (Jiri).
      RFCv2:
       - remove the nesting in attr DEVLINK_ATTR_INFO_VERSIONS (now
         versions are mixed with other info attrs)l
       - have the driver report versions from the same callback as
         other info.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc6fae7d
    • J
      devlink: add device information API · f9cf2288
      Jakub Kicinski 提交于
      ethtool -i has served us well for a long time, but its showing
      its limitations more and more. The device information should
      also be reported per device not per-netdev.
      
      Lay foundation for a simple devlink-based way of reading device
      info. Add driver name and device serial number as initial pieces
      of information exposed via this new API.
      
      v3:
       - rename helpers (Jiri);
       - rename driver name attr (Jiri);
       - remove double spacing in commit message (Jiri).
      RFC v2:
       - wrap the skb into an opaque structure (Jiri);
       - allow the serial number of be any length (Jiri & Andrew);
       - add driver name (Jonathan).
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9cf2288
    • D
      net: tls: Add tls 1.3 support · 130b392c
      Dave Watson 提交于
      TLS 1.3 has minor changes from TLS 1.2 at the record layer.
      
      * Header now hardcodes the same version and application content type in
        the header.
      * The real content type is appended after the data, before encryption (or
        after decryption).
      * The IV is xored with the sequence number, instead of concatinating four
        bytes of IV with the explicit IV.
      * Zero-padding:  No exlicit length is given, we search backwards from the
        end of the decrypted data for the first non-zero byte, which is the
        content type.  Currently recv supports reading zero-padding, but there
        is no way for send to add zero padding.
      Signed-off-by: NDave Watson <davejwatson@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      130b392c
    • D
      net: tls: Support 256 bit keys · fb99bce7
      Dave Watson 提交于
      Wire up support for 256 bit keys from the setsockopt to the crypto
      framework
      Signed-off-by: NDave Watson <davejwatson@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb99bce7
    • A
      bpf: introduce BPF_F_LOCK flag · 96049f3a
      Alexei Starovoitov 提交于
      Introduce BPF_F_LOCK flag for map_lookup and map_update syscall commands
      and for map_update() helper function.
      In all these cases take a lock of existing element (which was provided
      in BTF description) before copying (in or out) the rest of map value.
      
      Implementation details that are part of uapi:
      
      Array:
      The array map takes the element lock for lookup/update.
      
      Hash:
      hash map also takes the lock for lookup/update and tries to avoid the bucket lock.
      If old element exists it takes the element lock and updates the element in place.
      If element doesn't exist it allocates new one and inserts into hash table
      while holding the bucket lock.
      In rare case the hashmap has to take both the bucket lock and the element lock
      to update old value in place.
      
      Cgroup local storage:
      It is similar to array. update in place and lookup are done with lock taken.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      96049f3a
    • A
      bpf: introduce bpf_spin_lock · d83525ca
      Alexei Starovoitov 提交于
      Introduce 'struct bpf_spin_lock' and bpf_spin_lock/unlock() helpers to let
      bpf program serialize access to other variables.
      
      Example:
      struct hash_elem {
          int cnt;
          struct bpf_spin_lock lock;
      };
      struct hash_elem * val = bpf_map_lookup_elem(&hash_map, &key);
      if (val) {
          bpf_spin_lock(&val->lock);
          val->cnt++;
          bpf_spin_unlock(&val->lock);
      }
      
      Restrictions and safety checks:
      - bpf_spin_lock is only allowed inside HASH and ARRAY maps.
      - BTF description of the map is mandatory for safety analysis.
      - bpf program can take one bpf_spin_lock at a time, since two or more can
        cause dead locks.
      - only one 'struct bpf_spin_lock' is allowed per map element.
        It drastically simplifies implementation yet allows bpf program to use
        any number of bpf_spin_locks.
      - when bpf_spin_lock is taken the calls (either bpf2bpf or helpers) are not allowed.
      - bpf program must bpf_spin_unlock() before return.
      - bpf program can access 'struct bpf_spin_lock' only via
        bpf_spin_lock()/bpf_spin_unlock() helpers.
      - load/store into 'struct bpf_spin_lock lock;' field is not allowed.
      - to use bpf_spin_lock() helper the BTF description of map value must be
        a struct and have 'struct bpf_spin_lock anyname;' field at the top level.
        Nested lock inside another struct is not allowed.
      - syscall map_lookup doesn't copy bpf_spin_lock field to user space.
      - syscall map_update and program map_update do not update bpf_spin_lock field.
      - bpf_spin_lock cannot be on the stack or inside networking packet.
        bpf_spin_lock can only be inside HASH or ARRAY map value.
      - bpf_spin_lock is available to root only and to all program types.
      - bpf_spin_lock is not allowed in inner maps of map-in-map.
      - ld_abs is not allowed inside spin_lock-ed region.
      - tracing progs and socket filter progs cannot use bpf_spin_lock due to
        insufficient preemption checks
      
      Implementation details:
      - cgroup-bpf class of programs can nest with xdp/tc programs.
        Hence bpf_spin_lock is equivalent to spin_lock_irqsave.
        Other solutions to avoid nested bpf_spin_lock are possible.
        Like making sure that all networking progs run with softirq disabled.
        spin_lock_irqsave is the simplest and doesn't add overhead to the
        programs that don't use it.
      - arch_spinlock_t is used when its implemented as queued_spin_lock
      - archs can force their own arch_spinlock_t
      - on architectures where queued_spin_lock is not available and
        sizeof(arch_spinlock_t) != sizeof(__u32) trivial lock is used.
      - presence of bpf_spin_lock inside map value could have been indicated via
        extra flag during map_create, but specifying it via BTF is cleaner.
        It provides introspection for map key/value and reduces user mistakes.
      
      Next steps:
      - allow bpf_spin_lock in other map types (like cgroup local storage)
      - introduce BPF_F_LOCK flag for bpf_map_update() syscall and helper
        to request kernel to grab bpf_spin_lock before rewriting the value.
        That will serialize access to map elements.
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d83525ca
  8. 30 1月, 2019 4 次提交
  9. 27 1月, 2019 1 次提交
  10. 26 1月, 2019 3 次提交
    • L
      nl80211: Allow set/del pmksa operations for AP · 6c900360
      Liangwei Dong 提交于
      Host drivers may offload authentication to the user space
      through the commit ("cfg80211: Authentication offload to
      user space in AP mode").
      
      This interface can be used to implement SAE by having the
      userspace do authentication/PMKID key derivation and driver
      handle the association.
      
      A step ahead, this interface can get further optimized if the
      PMKID is passed to the host driver and also have it respond to
      the association request by the STA on a valid PMKID.
      
      This commit enables the userspace to pass the PMKID to the host
      drivers through the set/del pmksa operations in AP mode.
      
      Set/Del pmksa is now restricted to STA/P2P client mode only and
      thus the drivers might not expect them in any other(AP) mode.
      
      This commit also introduces a feature flag
      NL80211_EXT_FEATURE_AP_PMKSA_CACHING (johannes: renamed) to
      maintain the backward compatibility of such an expectation by
      the host drivers. These operations are allowed in AP mode only
      when the drivers advertize the capability through this flag.
      Signed-off-by: NLiangwei Dong <liangwei@codeaurora.org>
      Signed-off-by: NSrinivas Dasari <dasaris@codeaurora.org>
      [rename flag to NL80211_EXT_FEATURE_AP_PMKSA_CACHING]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6c900360
    • S
      cfg80211: Authentication offload to user space in AP mode · fe494370
      Srinivas Dasari 提交于
      commit 40cbfa90 ("cfg80211/nl80211: Optional authentication
      offload to userspace")' introduced authentication offload to user
      space by the host drivers in station mode. This commit extends
      the same for the AP mode too.
      
      Extend NL80211_ATTR_EXTERNAL_AUTH_SUPPORT to also claim the
      support of external authentication from the user space in AP mode.
      A new flag parameter is introduced in cfg80211_ap_settings to
      intend the same while "start ap".
      
      Host driver to use NL80211_CMD_FRAME interface to transmit and
      receive the authentication frames to / from the user space.
      
      Host driver to indicate the flag NL80211_RXMGMT_FLAG_EXTERNAL_AUTH
      while sending the authentication frame to the user space. This
      intends to the user space that the driver wishes it to process
      the authentication frame for certain protocols, though it had
      initially advertised the support for SME functionality.
      
      User space shall accordingly do the authentication and indicate
      its final status through the command NL80211_CMD_EXTERNAL_AUTH.
      Allow the command even if userspace doesn't include the attribute
      NL80211_ATTR_SSID for AP interface.
      
      Host driver shall continue with the association sequence and
      indicate the STA connection status through cfg80211_new_sta.
      
      To facilitate the host drivers in AP mode for matching the pmkid
      by the stations during the association, NL80211_CMD_EXTERNAL_AUTH
      is also enhanced to include the pmkid to drivers after
      the authentication.
      This pmkid can also be used in the STA mode to include in the
      association request.
      
      Also modify nl80211_external_auth to not mandate SSID in AP mode.
      Signed-off-by: NSrinivas Dasari <dasaris@codeaurora.org>
      [remove useless nla_get_flag() usage]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe494370
    • D
      net: Revert devlink health changes. · 30e5c2c6
      David S. Miller 提交于
      This reverts the devlink health changes from 9/17/2019,
      Jiri wants things to be designed differently and it was
      agreed that the easiest way to do this is start from the
      beginning again.
      
      Commits reverted:
      
      cb5ccfbe
      880ee82f
      c7af343b
      ff253fed
      6f9d5613
      fcd852c6
      8a66704a
      12bd0dce
      aba25279
      ce019faa
      b8c45a03
      
      And the follow-on build fix:
      
      o33a0efa4Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30e5c2c6
  11. 25 1月, 2019 3 次提交
  12. 24 1月, 2019 3 次提交
  13. 23 1月, 2019 3 次提交
    • L
      bridge: Snoop Multicast Router Advertisements · 4b3087c7
      Linus Lüssing 提交于
      When multiple multicast routers are present in a broadcast domain then
      only one of them will be detectable via IGMP/MLD query snooping. The
      multicast router with the lowest IP address will become the selected and
      active querier while all other multicast routers will then refrain from
      sending queries.
      
      To detect such rather silent multicast routers, too, RFC4286
      ("Multicast Router Discovery") provides a standardized protocol to
      detect multicast routers for multicast snooping switches.
      
      This patch implements the necessary MRD Advertisement message parsing
      and after successful processing adds such routers to the internal
      multicast router list.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b3087c7
    • L
      bridge: join all-snoopers multicast address · 4effd28c
      Linus Lüssing 提交于
      Next to snooping IGMP/MLD queries RFC4541, section 2.1.1.a) recommends
      to snoop multicast router advertisements to detect multicast routers.
      
      Multicast router advertisements are sent to an "all-snoopers"
      multicast address. To be able to receive them reliably, we need to
      join this group.
      
      Otherwise other snooping switches might refrain from forwarding these
      advertisements to us.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4effd28c
    • N
      bonding: add support for xstats and export 3ad stats · a258aeac
      Nikolay Aleksandrov 提交于
      This patch adds support for extended statistics (xstats) call to the
      bonding. The first user would be the 3ad code which counts the following
      events:
       - LACPDU Rx/Tx
       - LACPDU unknown type Rx
       - LACPDU illegal Rx
       - Marker Rx/Tx
       - Marker response Rx/Tx
       - Marker unknown type Rx
      
      All of these are exported via netlink as separate attributes to be
      easily extensible as we plan to add more in the future.
      Similar to how the bridge and other xstats exports, the structure
      inside is:
       [ IFLA_STATS_LINK_XSTATS ]
         -> [ LINK_XSTATS_TYPE_BOND ]
              -> [ BOND_XSTATS_3AD ]
                   -> [ 3ad stats attributes ]
      
      With this structure it's easy to add more stat types later.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a258aeac
  14. 22 1月, 2019 2 次提交