1. 13 2月, 2021 1 次提交
  2. 28 1月, 2021 1 次提交
    • N
      net: bridge: multicast: make tracked EHT hosts limit configurable · 2dba407f
      Nikolay Aleksandrov 提交于
      Add two new port attributes which make EHT hosts limit configurable and
      export the current number of tracked EHT hosts:
       - IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT: configure/retrieve current limit
       - IFLA_BRPORT_MCAST_EHT_HOSTS_CNT: current number of tracked hosts
      Setting IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT to 0 is currently not allowed.
      
      Note that we have to increase RTNL_SLAVE_MAX_TYPE to 38 minimum, I've
      increased it to 40 to have space for two more future entries.
      
      v2: move br_multicast_eht_set_hosts_limit() to br_multicast_eht.c,
          no functional change
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      2dba407f
  3. 19 1月, 2021 1 次提交
  4. 19 11月, 2020 1 次提交
  5. 30 10月, 2020 4 次提交
    • H
      bridge: cfm: Netlink Notifications. · b6d0425b
      Henrik Bjoernlund 提交于
      This is the implementation of Netlink notifications out of CFM.
      
      Notifications are initiated whenever a state change happens in CFM.
      
      IFLA_BRIDGE_CFM:
          Points to the CFM information.
      
      IFLA_BRIDGE_CFM_MEP_STATUS_INFO:
          This indicate that the MEP instance status are following.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO:
          This indicate that the peer MEP status are following.
      
      CFM nested attribute has the following attributes in next level.
      
      IFLA_BRIDGE_CFM_MEP_STATUS_INSTANCE:
          The MEP instance number of the delivered status.
          The type is NLA_U32.
      IFLA_BRIDGE_CFM_MEP_STATUS_OPCODE_UNEXP_SEEN:
          The MEP instance received CFM PDU with unexpected Opcode.
          The type is NLA_U32 (bool).
      IFLA_BRIDGE_CFM_MEP_STATUS_VERSION_UNEXP_SEEN:
          The MEP instance received CFM PDU with unexpected version.
          The type is NLA_U32 (bool).
      IFLA_BRIDGE_CFM_MEP_STATUS_RX_LEVEL_LOW_SEEN:
          The MEP instance received CCM PDU with MD level lower than
          configured level. This frame is discarded.
          The type is NLA_U32 (bool).
      
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_INSTANCE:
          The MEP instance number of the delivered status.
          The type is NLA_U32.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_PEER_MEPID:
          The added Peer MEP ID of the delivered status.
          The type is NLA_U32.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_CCM_DEFECT:
          The CCM defect status.
          The type is NLA_U32 (bool).
          True means no CCM frame is received for 3.25 intervals.
          IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_RDI:
          The last received CCM PDU RDI.
          The type is NLA_U32 (bool).
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_PORT_TLV_VALUE:
          The last received CCM PDU Port Status TLV value field.
          The type is NLA_U8.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_IF_TLV_VALUE:
          The last received CCM PDU Interface Status TLV value field.
          The type is NLA_U8.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEEN:
          A CCM frame has been received from Peer MEP.
          The type is NLA_U32 (bool).
          This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_TLV_SEEN:
          A CCM frame with TLV has been received from Peer MEP.
          The type is NLA_U32 (bool).
          This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
      IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEQ_UNEXP_SEEN:
          A CCM frame with unexpected sequence number has been received
          from Peer MEP.
          The type is NLA_U32 (bool).
          When a sequence number is not one higher than previously received
          then it is unexpected.
          This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
      Signed-off-by: NHenrik Bjoernlund  <henrik.bjoernlund@microchip.com>
      Reviewed-by: NHoratiu Vultur  <horatiu.vultur@microchip.com>
      Acked-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b6d0425b
    • H
      bridge: cfm: Netlink GET status Interface. · e77824d8
      Henrik Bjoernlund 提交于
      This is the implementation of CFM netlink status
      get information interface.
      
      Add new nested netlink attributes. These attributes are used by the
      user space to get status information.
      
      GETLINK:
          Request filter RTEXT_FILTER_CFM_STATUS:
          Indicating that CFM status information must be delivered.
      
          IFLA_BRIDGE_CFM:
              Points to the CFM information.
      
          IFLA_BRIDGE_CFM_MEP_STATUS_INFO:
              This indicate that the MEP instance status are following.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO:
              This indicate that the peer MEP status are following.
      
      CFM nested attribute has the following attributes in next level.
      
      GETLINK RTEXT_FILTER_CFM_STATUS:
          IFLA_BRIDGE_CFM_MEP_STATUS_INSTANCE:
              The MEP instance number of the delivered status.
              The type is u32.
          IFLA_BRIDGE_CFM_MEP_STATUS_OPCODE_UNEXP_SEEN:
              The MEP instance received CFM PDU with unexpected Opcode.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_MEP_STATUS_VERSION_UNEXP_SEEN:
              The MEP instance received CFM PDU with unexpected version.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_MEP_STATUS_RX_LEVEL_LOW_SEEN:
              The MEP instance received CCM PDU with MD level lower than
              configured level. This frame is discarded.
              The type is u32 (bool).
      
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_INSTANCE:
              The MEP instance number of the delivered status.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_PEER_MEPID:
              The added Peer MEP ID of the delivered status.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_CCM_DEFECT:
              The CCM defect status.
              The type is u32 (bool).
              True means no CCM frame is received for 3.25 intervals.
              IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_RDI:
              The last received CCM PDU RDI.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_PORT_TLV_VALUE:
              The last received CCM PDU Port Status TLV value field.
              The type is u8.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_IF_TLV_VALUE:
              The last received CCM PDU Interface Status TLV value field.
              The type is u8.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEEN:
              A CCM frame has been received from Peer MEP.
              The type is u32 (bool).
              This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_TLV_SEEN:
              A CCM frame with TLV has been received from Peer MEP.
              The type is u32 (bool).
              This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
          IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEQ_UNEXP_SEEN:
              A CCM frame with unexpected sequence number has been received
              from Peer MEP.
              The type is u32 (bool).
              When a sequence number is not one higher than previously received
              then it is unexpected.
              This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
      Signed-off-by: NHenrik Bjoernlund  <henrik.bjoernlund@microchip.com>
      Reviewed-by: NHoratiu Vultur  <horatiu.vultur@microchip.com>
      Acked-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      e77824d8
    • H
      bridge: cfm: Netlink GET configuration Interface. · 5e312fc0
      Henrik Bjoernlund 提交于
      This is the implementation of CFM netlink configuration
      get information interface.
      
      Add new nested netlink attributes. These attributes are used by the
      user space to get configuration information.
      
      GETLINK:
          Request filter RTEXT_FILTER_CFM_CONFIG:
          Indicating that CFM configuration information must be delivered.
      
          IFLA_BRIDGE_CFM:
              Points to the CFM information.
      
          IFLA_BRIDGE_CFM_MEP_CREATE_INFO:
              This indicate that MEP instance create parameters are following.
          IFLA_BRIDGE_CFM_MEP_CONFIG_INFO:
              This indicate that MEP instance config parameters are following.
          IFLA_BRIDGE_CFM_CC_CONFIG_INFO:
              This indicate that MEP instance CC functionality
              parameters are following.
          IFLA_BRIDGE_CFM_CC_RDI_INFO:
              This indicate that CC transmitted CCM PDU RDI
              parameters are following.
          IFLA_BRIDGE_CFM_CC_CCM_TX_INFO:
              This indicate that CC transmitted CCM PDU parameters are
              following.
          IFLA_BRIDGE_CFM_CC_PEER_MEP_INFO:
              This indicate that the added peer MEP IDs are following.
      
      CFM nested attribute has the following attributes in next level.
      
      GETLINK RTEXT_FILTER_CFM_CONFIG:
          IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE:
              The created MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN:
              The created MEP domain.
              The type is u32 (br_cfm_domain).
              It must be BR_CFM_PORT.
              This means that CFM frames are transmitted and received
              directly on the port - untagged. Not in a VLAN.
          IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION:
              The created MEP direction.
              The type is u32 (br_cfm_mep_direction).
              It must be BR_CFM_MEP_DIRECTION_DOWN.
              This means that CFM frames are transmitted and received on
              the port. Not in the bridge.
          IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX:
              The created MEP residence port ifindex.
              The type is u32 (ifindex).
      
          IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE:
              The deleted MEP instance number.
              The type is u32.
      
          IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC:
              The configured MEP unicast MAC address.
              The type is 6*u8 (array).
              This is used as SMAC in all transmitted CFM frames.
          IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL:
              The configured MEP unicast MD level.
              The type is u32.
              It must be in the range 1-7.
              No CFM frames are passing through this MEP on lower levels.
          IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID:
              The configured MEP ID.
              The type is u32.
              It must be in the range 0-0x1FFF.
              This MEP ID is inserted in any transmitted CCM frame.
      
          IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE:
              The Continuity Check (CC) functionality is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL:
              The CC expected receive interval of CCM frames.
              The type is u32 (br_cfm_ccm_interval).
              This is also the transmission interval of CCM frames when enabled.
          IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID:
              The CC expected receive MAID in CCM frames.
              The type is CFM_MAID_LENGTH*u8.
              This is MAID is also inserted in transmitted CCM frames.
      
          IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_PEER_MEPID:
              The CC Peer MEP ID added.
              The type is u32.
              When a Peer MEP ID is added and CC is enabled it is expected to
              receive CCM frames from that Peer MEP.
      
          IFLA_BRIDGE_CFM_CC_RDI_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_RDI_RDI:
              The RDI that is inserted in transmitted CCM PDU.
              The type is u32 (bool).
      
          IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC:
              The transmitted CCM frame destination MAC address.
              The type is 6*u8 (array).
              This is used as DMAC in all transmitted CFM frames.
          IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE:
              The transmitted CCM frame update (increment) of sequence
              number is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD:
              The period of time where CCM frame are transmitted.
              The type is u32.
              The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX
              must be done before timeout to keep transmission alive.
              When period is zero any ongoing CCM frame transmission
              will be stopped.
          IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV:
              The transmitted CCM frame update with Interface Status TLV
              is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE:
              The transmitted Interface Status TLV value field.
              The type is u8.
          IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV:
              The transmitted CCM frame update with Port Status TLV is enabled
              or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE:
              The transmitted Port Status TLV value field.
              The type is u8.
      Signed-off-by: NHenrik Bjoernlund  <henrik.bjoernlund@microchip.com>
      Reviewed-by: NHoratiu Vultur  <horatiu.vultur@microchip.com>
      Acked-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      5e312fc0
    • H
      bridge: cfm: Netlink SET configuration Interface. · 2be665c3
      Henrik Bjoernlund 提交于
      This is the implementation of CFM netlink configuration
      set information interface.
      
      Add new nested netlink attributes. These attributes are used by the
      user space to create/delete/configure CFM instances.
      
      SETLINK:
          IFLA_BRIDGE_CFM:
              Indicate that the following attributes are CFM.
      
          IFLA_BRIDGE_CFM_MEP_CREATE:
              This indicate that a MEP instance must be created.
          IFLA_BRIDGE_CFM_MEP_DELETE:
              This indicate that a MEP instance must be deleted.
          IFLA_BRIDGE_CFM_MEP_CONFIG:
              This indicate that a MEP instance must be configured.
          IFLA_BRIDGE_CFM_CC_CONFIG:
              This indicate that a MEP instance Continuity Check (CC)
              functionality must be configured.
          IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD:
              This indicate that a CC Peer MEP must be added.
          IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE:
              This indicate that a CC Peer MEP must be removed.
          IFLA_BRIDGE_CFM_CC_CCM_TX:
              This indicate that the CC transmitted CCM PDU must be configured.
          IFLA_BRIDGE_CFM_CC_RDI:
              This indicate that the CC transmitted CCM PDU RDI must be
              configured.
      
      CFM nested attribute has the following attributes in next level.
      
      SETLINK RTEXT_FILTER_CFM_CONFIG:
          IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE:
              The created MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN:
              The created MEP domain.
              The type is u32 (br_cfm_domain).
              It must be BR_CFM_PORT.
              This means that CFM frames are transmitted and received
              directly on the port - untagged. Not in a VLAN.
          IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION:
              The created MEP direction.
              The type is u32 (br_cfm_mep_direction).
              It must be BR_CFM_MEP_DIRECTION_DOWN.
              This means that CFM frames are transmitted and received on
              the port. Not in the bridge.
          IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX:
              The created MEP residence port ifindex.
              The type is u32 (ifindex).
      
          IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE:
              The deleted MEP instance number.
              The type is u32.
      
          IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC:
              The configured MEP unicast MAC address.
              The type is 6*u8 (array).
              This is used as SMAC in all transmitted CFM frames.
          IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL:
              The configured MEP unicast MD level.
              The type is u32.
              It must be in the range 1-7.
              No CFM frames are passing through this MEP on lower levels.
          IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID:
              The configured MEP ID.
              The type is u32.
              It must be in the range 0-0x1FFF.
              This MEP ID is inserted in any transmitted CCM frame.
      
          IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE:
              The Continuity Check (CC) functionality is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL:
              The CC expected receive interval of CCM frames.
              The type is u32 (br_cfm_ccm_interval).
              This is also the transmission interval of CCM frames when enabled.
          IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID:
              The CC expected receive MAID in CCM frames.
              The type is CFM_MAID_LENGTH*u8.
              This is MAID is also inserted in transmitted CCM frames.
      
          IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_PEER_MEPID:
              The CC Peer MEP ID added.
              The type is u32.
              When a Peer MEP ID is added and CC is enabled it is expected to
              receive CCM frames from that Peer MEP.
      
          IFLA_BRIDGE_CFM_CC_RDI_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_RDI_RDI:
              The RDI that is inserted in transmitted CCM PDU.
              The type is u32 (bool).
      
          IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE:
              The configured MEP instance number.
              The type is u32.
          IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC:
              The transmitted CCM frame destination MAC address.
              The type is 6*u8 (array).
              This is used as DMAC in all transmitted CFM frames.
          IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE:
              The transmitted CCM frame update (increment) of sequence
              number is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD:
              The period of time where CCM frame are transmitted.
              The type is u32.
              The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX
              must be done before timeout to keep transmission alive.
              When period is zero any ongoing CCM frame transmission
              will be stopped.
          IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV:
              The transmitted CCM frame update with Interface Status TLV
              is enabled or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE:
              The transmitted Interface Status TLV value field.
              The type is u8.
          IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV:
              The transmitted CCM frame update with Port Status TLV is enabled
              or disabled.
              The type is u32 (bool).
          IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE:
              The transmitted Port Status TLV value field.
              The type is u8.
      Signed-off-by: NHenrik Bjoernlund  <henrik.bjoernlund@microchip.com>
      Reviewed-by: NHoratiu Vultur  <horatiu.vultur@microchip.com>
      Acked-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      2be665c3
  6. 09 10月, 2020 1 次提交
  7. 19 8月, 2020 1 次提交
  8. 15 7月, 2020 1 次提交
  9. 03 7月, 2020 1 次提交
  10. 01 5月, 2020 1 次提交
  11. 28 4月, 2020 3 次提交
  12. 15 1月, 2020 5 次提交
  13. 15 12月, 2019 1 次提交
  14. 31 5月, 2019 1 次提交
  15. 28 4月, 2019 3 次提交
    • J
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg 提交于
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb08174
    • M
      net: fix two coding style issues · f78c6032
      Michal Kubecek 提交于
      This is a simple cleanup addressing two coding style issues found by
      checkpatch.pl in an earlier patch. It's submitted as a separate patch to
      keep the original patch as it was generated by spatch.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f78c6032
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  16. 17 4月, 2019 1 次提交
  17. 30 3月, 2019 1 次提交
  18. 19 12月, 2018 1 次提交
  19. 13 12月, 2018 2 次提交
  20. 06 12月, 2018 2 次提交
    • N
      net: bridge: mark hash_elasticity as obsolete · cf332bca
      Nikolay Aleksandrov 提交于
      Now that the bridge multicast uses the generic rhashtable interface we
      can drop the hash_elasticity option as that is already done for us and
      it's hardcoded to a maximum of RHT_ELASTICITY (16 currently). Add a
      warning about the obsolete option when the hash_elasticity is set.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf332bca
    • N
      net: bridge: convert multicast to generic rhashtable · 19e3a9c9
      Nikolay Aleksandrov 提交于
      The bridge multicast code currently uses a custom resizable hashtable
      which predates the generic rhashtable interface. It has many
      shortcomings compared and duplicates functionality that is presently
      available via the generic rhashtable, so this patch removes the custom
      rhashtable implementation in favor of the kernel's generic rhashtable.
      The hash maximum is kept and the rhashtable's size is used to do a loose
      check if it's reached in which case we revert to the old behaviour and
      disable further bridge multicast processing. Also now we can support any
      hash maximum, doesn't need to be a power of 2.
      
      v3: add non-rcu br_mdb_get variant and use it where multicast_lock is
          held to avoid RCU splat, drop hash_max function and just set it
          directly
      
      v2: handle when IGMP snooping is undefined, add br_mdb_init/uninit
          placeholders
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19e3a9c9
  21. 28 11月, 2018 1 次提交
    • N
      net: bridge: add support for user-controlled bool options · a428afe8
      Nikolay Aleksandrov 提交于
      We have been adding many new bridge options, a big number of which are
      boolean but still take up netlink attribute ids and waste space in the skb.
      Recently we discussed learning from link-local packets[1] and decided
      yet another new boolean option will be needed, thus introducing this API
      to save some bridge nl space.
      The API supports changing the value of multiple boolean options at once
      via the br_boolopt_multi struct which has an optmask (which options to
      set, bit per opt) and optval (options' new values). Future boolean
      options will only be added to the br_boolopt_id enum and then will have
      to be handled in br_boolopt_toggle/get. The API will automatically
      add the ability to change and export them via netlink, sysfs can use the
      single boolopt function versions to do the same. The behaviour with
      failing/succeeding is the same as with normal netlink option changing.
      
      If an option requires mapping to internal kernel flag or needs special
      configuration to be enabled then it should be handled in
      br_boolopt_toggle. It should also be able to retrieve an option's current
      state via br_boolopt_get.
      
      v2: WARN_ON() on unsupported option as that shouldn't be possible and
          also will help catch people who add new options without handling
          them for both set and get. Pass down extack so if an option desires
          it could set it on error and be more user-friendly.
      
      [1] https://www.spinics.net/lists/netdev/msg532698.htmlSigned-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a428afe8
  22. 13 10月, 2018 1 次提交
    • N
      net: bridge: add support for per-port vlan stats · 9163a0fc
      Nikolay Aleksandrov 提交于
      This patch adds an option to have per-port vlan stats instead of the
      default global stats. The option can be set only when there are no port
      vlans in the bridge since we need to allocate the stats if it is set
      when vlans are being added to ports (and respectively free them
      when being deleted). Also bump RTNL_MAX_TYPE as the bridge is the
      largest user of options. The current stats design allows us to add
      these without any changes to the fast-path, it all comes down to
      the per-vlan stats pointer which, if this option is enabled, will
      be allocated for each port vlan instead of using the global bridge-wide
      one.
      
      CC: bridge@lists.linux-foundation.org
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9163a0fc
  23. 27 9月, 2018 5 次提交