1. 10 7月, 2019 2 次提交
  2. 15 6月, 2019 2 次提交
  3. 09 6月, 2019 1 次提交
  4. 31 5月, 2019 1 次提交
  5. 30 5月, 2019 2 次提交
  6. 13 5月, 2019 1 次提交
    • V
      net: dsa: Initialize DSA_SKB_CB(skb)->deferred_xmit variable · 87671375
      Vladimir Oltean 提交于
      The sk_buff control block can have any contents on xmit put there by the
      stack, so initialization is mandatory, since we are checking its value
      after the actual DSA xmit (the tagger may have changed it).
      
      The DSA_SKB_ZERO() macro could have been used for this purpose, but:
      - Zeroizing a 48-byte memory region in the hotpath is best avoided.
      - It would have triggered a warning with newer compilers since
        __dsa_skb_cb contains a structure within a structure, and the {0}
        initializer was incorrect for that purpose.
      
      So simply remove the DSA_SKB_ZERO() macro and initialize the
      deferred_xmit variable by hand (which should be done for all further
      dsa_skb_cb variables which need initialization - currently none - to
      avoid the performance penalty).
      
      Fixes: 97a69a0d ("net: dsa: Add support for deferred xmit")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87671375
  7. 08 5月, 2019 1 次提交
  8. 06 5月, 2019 2 次提交
    • V
      net: dsa: Add support for deferred xmit · 97a69a0d
      Vladimir Oltean 提交于
      Some hardware needs to take work to get convinced to receive frames on
      the CPU port (such as the sja1105 which takes temporary L2 forwarding
      rules over SPI that last for a single frame). Such work needs a
      sleepable context, and because the regular .ndo_start_xmit is atomic,
      this cannot be done in the tagger. So introduce a generic DSA mechanism
      that sets up a transmit skb queue and a workqueue for deferred
      transmission.
      
      The new driver callback (.port_deferred_xmit) is in dsa_switch and not
      in the tagger because the operations that require sleeping typically
      also involve interacting with the hardware, and not simply skb
      manipulations. Therefore having it there simplifies the structure a bit
      and makes it unnecessary to export functions from the driver to the
      tagger.
      
      The driver is responsible of calling dsa_enqueue_skb which transfers it
      to the master netdevice. This is so that it has a chance of performing
      some more work afterwards, such as cleanup or TX timestamping.
      
      To tell DSA that skb xmit deferral is required, I have thought about
      changing the return type of the tagger .xmit from struct sk_buff * into
      a enum dsa_tx_t that could potentially encode a DSA_XMIT_DEFER value.
      
      But the trailer tagger is reallocating every skb on xmit and therefore
      making a valid use of the pointer return value. So instead of reworking
      the API in complicated ways, right now a boolean property in the newly
      introduced DSA_SKB_CB is set.
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a69a0d
    • P
      net/dsa: use intermediate representation for matchall offload · 9681e8b3
      Pieter Jansen van Vuuren 提交于
      Updates dsa hardware switch handling infrastructure to use the newer
      intermediate representation for flow actions in matchall offloads.
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9681e8b3
  9. 01 5月, 2019 1 次提交
  10. 05 4月, 2019 1 次提交
  11. 02 4月, 2019 1 次提交
  12. 29 3月, 2019 2 次提交
  13. 27 3月, 2019 1 次提交
  14. 04 3月, 2019 1 次提交
  15. 28 2月, 2019 2 次提交
  16. 25 2月, 2019 1 次提交
  17. 23 2月, 2019 2 次提交
    • F
      net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation · 061f6a50
      Florian Fainelli 提交于
      In order to properly support VLAN filtering being enabled/disabled on a
      bridge, while having other ports being non bridge port members, we need
      to support the ndo_vlan_rx_{add,kill}_vid callbacks in order to make
      sure the non-bridge ports can continue receiving VLAN tags, even when
      the switch is globally configured to do ingress/egress VID checking.
      
      Since we can call dsa_port_vlan_{add,del} with a bridge_dev pointer
      NULL, we now need to check that in these two functions.
      
      We specifically deal with two possibly problematic cases:
      
      - creating a bridge VLAN entry while there is an existing VLAN device
        claiming that same VID
      
      - creating a VLAN device while there is an existing bridge VLAN entry
        with that VID
      
      Those are both resolved with returning -EBUSY back to user-space.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      061f6a50
    • F
      net: dsa: Deny enslaving VLAN devices into VLAN aware bridge · cc1d5bda
      Florian Fainelli 提交于
      VLAN devices on top of a DSA network device which is already part of a
      bridge and with said bridge being VLAN aware should not be allowed to be
      enslaved into that bridge. For one, this duplicates functionality
      offered by the VLAN aware bridge which supports tagged and untagged VLAN
      frames processing and it would make things needlessly complex to e.g.:
      propagate FDB/MDB accordingly.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc1d5bda
  18. 22 2月, 2019 4 次提交
  19. 07 2月, 2019 2 次提交
  20. 05 2月, 2019 1 次提交
    • R
      net: dsa: slave: Don't propagate flag changes on down slave interfaces · 17ab4f61
      Rundong Ge 提交于
      The unbalance of master's promiscuity or allmulti will happen after ifdown
      and ifup a slave interface which is in a bridge.
      
      When we ifdown a slave interface , both the 'dsa_slave_close' and
      'dsa_slave_change_rx_flags' will clear the master's flags. The flags
      of master will be decrease twice.
      In the other hand, if we ifup the slave interface again, since the
      slave's flags were cleared the 'dsa_slave_open' won't set the master's
      flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if'
      will set the master's flags. The flags of master is increase once.
      
      Only propagating flag changes when a slave interface is up makes
      sure this does not happen. The 'vlan_dev_change_rx_flags' had the
      same problem and was fixed, and changes here follows that fix.
      
      Fixes: 91da11f8 ("net: Distributed Switch Architecture protocol support")
      Signed-off-by: NRundong Ge <rdong.ge@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17ab4f61
  21. 18 1月, 2019 2 次提交
  22. 01 12月, 2018 1 次提交
  23. 24 11月, 2018 2 次提交
    • P
      switchdev: Replace port obj add/del SDO with a notification · d17d9f5e
      Petr Machata 提交于
      Drop switchdev_ops.switchdev_port_obj_add and _del. Drop the uses of
      this field from all clients, which were migrated to use switchdev
      notification in the previous patches.
      
      Add a new function switchdev_port_obj_notify() that sends the switchdev
      notifications SWITCHDEV_PORT_OBJ_ADD and _DEL.
      
      Update switchdev_port_obj_del_now() to dispatch to this new function.
      Drop __switchdev_port_obj_add() and update switchdev_port_obj_add()
      likewise.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d17d9f5e
    • P
      net: dsa: slave: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL · 2b239f67
      Petr Machata 提交于
      Following patches will change the way of distributing port object
      changes from a switchdev operation to a switchdev notifier. The
      switchdev code currently recursively descends through layers of lower
      devices, eventually calling the op on a front-panel port device. The
      notifier will instead be sent referencing the bridge port device, which
      may be a stacking device that's one of front-panel ports uppers, or a
      completely unrelated device.
      
      DSA currently doesn't support any other uppers than bridge.
      SWITCHDEV_OBJ_ID_HOST_MDB and _PORT_MDB objects are always notified on
      the bridge port device. Thus the only case that a stacked device could
      be validly referenced by port object notifications are bridge
      notifications for VLAN objects added to the bridge itself. But the
      driver explicitly rejects such notifications in dsa_port_vlan_add(). It
      is therefore safe to assume that the only interesting case is that the
      notification is on a front-panel port netdevice. Therefore keep the
      filtering by dsa_slave_dev_check() in place.
      
      To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking
      notifier chain. Dispatch to rocker_port_obj_add() resp. _del() to
      maintain the behavior that the switchdev operation based code currently
      has.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b239f67
  24. 20 10月, 2018 1 次提交
    • D
      netpoll: allow cleanup to be synchronous · c9fbd71f
      Debabrata Banerjee 提交于
      This fixes a problem introduced by:
      commit 2cde6acd ("netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock")
      
      When using netconsole on a bond, __netpoll_cleanup can asynchronously
      recurse multiple times, each __netpoll_free_async call can result in
      more __netpoll_free_async's. This means there is now a race between
      cleanup_work queues on multiple netpoll_info's on multiple devices and
      the configuration of a new netpoll. For example if a netconsole is set
      to enable 0, reconfigured, and enable 1 immediately, this netconsole
      will likely not work.
      
      Given the reason for __netpoll_free_async is it can be called when rtnl
      is not locked, if it is locked, we should be able to execute
      synchronously. It appears to be locked everywhere it's called from.
      
      Generalize the design pattern from the teaming driver for current
      callers of __netpoll_free_async.
      
      CC: Neil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDebabrata Banerjee <dbanerje@akamai.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9fbd71f
  25. 18 10月, 2018 1 次提交
  26. 08 9月, 2018 1 次提交
  27. 22 8月, 2018 1 次提交