1. 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
  2. 08 5月, 2019 1 次提交
  3. 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
  4. 01 5月, 2019 1 次提交
  5. 05 4月, 2019 1 次提交
  6. 02 4月, 2019 1 次提交
  7. 29 3月, 2019 2 次提交
  8. 27 3月, 2019 1 次提交
  9. 04 3月, 2019 1 次提交
  10. 28 2月, 2019 2 次提交
  11. 25 2月, 2019 1 次提交
  12. 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
  13. 22 2月, 2019 4 次提交
  14. 07 2月, 2019 2 次提交
  15. 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
  16. 18 1月, 2019 2 次提交
  17. 01 12月, 2018 1 次提交
  18. 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
  19. 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
  20. 18 10月, 2018 1 次提交
  21. 08 9月, 2018 1 次提交
  22. 22 8月, 2018 1 次提交
  23. 09 8月, 2018 1 次提交
  24. 02 8月, 2018 1 次提交
  25. 26 6月, 2018 1 次提交
  26. 12 5月, 2018 3 次提交
    • F
      net: dsa: Plug in PHYLINK support · aab9c406
      Florian Fainelli 提交于
      Add support for PHYLINK within the DSA subsystem in order to support more
      complex devices such as pluggable (SFP) and non-pluggable (SFF) modules, 10G
      PHYs, and traditional PHYs. Using PHYLINK allows us to drop some amount of
      complexity we had while probing fixed and non-fixed PHYs using Device Tree.
      
      Because PHYLINK separates the Ethernet MAC/port configuration into different
      stages, we let switch drivers implement those, and for now, we maintain
      functionality by calling dsa_slave_adjust_link() during
      phylink_mac_link_{up,down} which provides semantically equivalent steps.
      
      Drivers willing to take advantage of PHYLINK should implement the phylink_mac_*
      operations that DSA wraps.
      
      We cannot quite remove the adjust_link() callback just yet, because a number of
      drivers rely on that for configuring their "CPU" and "DSA" ports, this is done
      dsa_port_setup_phy_of() and dsa_port_fixed_link_register_of() still.
      
      Drivers that utilize fixed links for user-facing ports (e.g: bcm_sf2) will need
      to implement phylink_mac_ops from now on to preserve functionality, since PHYLINK
      *does not* create a phy_device instance for fixed links.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aab9c406
    • F
      net: dsa: Eliminate dsa_slave_get_link() · c4aef9fc
      Florian Fainelli 提交于
      Since we use PHYLIB to manage the per-port link indication, this will
      also be reflected correctly in the network device's carrier state, so we
      can use ethtool_op_get_link() instead.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4aef9fc
    • F
      net: dsa: Add PHYLINK switch operations · 11d8f3dd
      Florian Fainelli 提交于
      In preparation for adding support for PHYLINK within DSA, define a number of
      operations that we will need and that switch drivers can start implementing.
      Proper integration with PHYLINK will follow in subsequent patches.
      
      We start selecting PHYLINK (which implies PHYLIB) in net/dsa/Kconfig
      such that drivers can be guaranteed that this dependency is properly
      taken care of and can start referencing PHYLINK helper functions without
      requiring stubs or anything.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d8f3dd
  27. 11 5月, 2018 1 次提交
    • V
      net: dsa: fix added_by_user switchdev notification · a37fb855
      Vivien Didelot 提交于
      Commit 161d82de ("net: bridge: Notify about !added_by_user FDB
      entries") causes the below oops when bringing up a slave interface,
      because dsa_port_fdb_add is still scheduled, but with a NULL address.
      
      To fix this, keep the dsa_slave_switchdev_event function agnostic of the
      notified info structure and handle the added_by_user flag in the
      specific dsa_slave_switchdev_event_work function.
      
          [   75.512263] Unable to handle kernel NULL pointer dereference at virtual address 00000000
          [   75.519063] pgd = (ptrval)
          [   75.520545] [00000000] *pgd=00000000
          [   75.522839] Internal error: Oops: 17 [#1] ARM
          [   75.525898] Modules linked in:
          [   75.527673] CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 4.17.0-rc2 #78
          [   75.532988] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
          [   75.538153] Workqueue: dsa_ordered dsa_slave_switchdev_event_work
          [   75.542970] PC is at mv88e6xxx_port_db_load_purge+0x60/0x1b0
          [   75.547341] LR is at mdiobus_read_nested+0x6c/0x78
          [   75.550833] pc : [<804cd5c0>]    lr : [<804bba84>]    psr: 60070013
          [   75.555796] sp : 9f54bd78  ip : 9f54bd87  fp : 9f54bddc
          [   75.559719] r10: 00000000  r9 : 0000000e  r8 : 9f6a6010
          [   75.563643] r7 : 00000000  r6 : 81203048  r5 : 9f6a6010  r4 : 9f6a601c
          [   75.568867] r3 : 00000000  r2 : 00000000  r1 : 0000000d  r0 : 00000000
          [   75.574094] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
          [   75.579933] Control: 10c53c7d  Table: 9de20059  DAC: 00000051
          [   75.584384] Process kworker/u2:1 (pid: 9, stack limit = 0x(ptrval))
          [   75.589349] Stack: (0x9f54bd78 to 0x9f54c000)
          [   75.592406] bd60:                                                       00000000 00000000
          [   75.599295] bd80: 00000391 9f299d10 9f299d68 8014317c 9f7f0000 8120af00 00006dc2 00000000
          [   75.606186] bda0: 8120af00 00000000 9f54bdec 1c9f5d92 8014317c 9f6a601c 9f6a6010 00000000
          [   75.613076] bdc0: 00000000 00000000 9dd1141c 8125a0b4 9f54be0c 9f54bde0 804cd8a8 804cd56c
          [   75.619966] bde0: 0000000e 80143680 00000001 9dce9c1c 81203048 9dce9c10 00000003 00000000
          [   75.626858] be00: 9f54be5c 9f54be10 806abcac 804cd864 9f54be54 80143664 8014317c 80143054
          [   75.633748] be20: ffcaa81d 00000000 812030b0 1c9f5d92 00000000 81203048 9f54beb4 00000003
          [   75.640639] be40: ffffffff 00000000 9dd1141c 8125a0b4 9f54be84 9f54be60 80138e98 806abb18
          [   75.647529] be60: 81203048 9ddc4000 9dce9c54 9f72a300 00000000 00000000 9f54be9c 9f54be88
          [   75.654420] be80: 801390bc 80138e50 00000000 9dce9c54 9f54beac 9f54bea0 806a9524 801390a0
          [   75.661310] bea0: 9f54bedc 9f54beb0 806a9c7c 806a950c 9f54becc 00000000 00000000 00000000
          [   75.668201] bec0: 9f540000 1c9f5d92 805fe604 9ddffc00 9f54befc 9f54bee0 806ab228 806a9c38
          [   75.675092] bee0: 806ab178 9ddffc00 9f4c1900 9f40d200 9f54bf34 9f54bf00 80131e30 806ab184
          [   75.681983] bf00: 9f40d214 9f54a038 9f40d200 9f40d200 9f4c1918 812119a0 9f40d214 9f54a038
          [   75.688873] bf20: 9f40d200 9f4c1900 9f54bf7c 9f54bf38 80132124 80131d1c 9f5f2dd8 00000000
          [   75.695764] bf40: 812119a0 9f54a038 812119a0 81259c5b 9f5f2dd8 9f5f2dc0 9f53dbc0 00000000
          [   75.702655] bf60: 9f4c1900 801320b4 9f5f2dd8 9f4f7e88 9f54bfac 9f54bf80 80137ad0 801320c0
          [   75.709544] bf80: 9f54a000 9f53dbc0 801379a0 00000000 00000000 00000000 00000000 00000000
          [   75.716434] bfa0: 00000000 9f54bfb0 801010e8 801379ac 00000000 00000000 00000000 00000000
          [   75.723324] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          [   75.730206] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
          [   75.737083] Backtrace:
          [   75.738252] [<804cd560>] (mv88e6xxx_port_db_load_purge) from [<804cd8a8>] (mv88e6xxx_port_fdb_add+0x50/0x68)
          [   75.746795]  r10:8125a0b4 r9:9dd1141c r8:00000000 r7:00000000 r6:00000000 r5:9f6a6010
          [   75.753323]  r4:9f6a601c
          [   75.754570] [<804cd858>] (mv88e6xxx_port_fdb_add) from [<806abcac>] (dsa_switch_event+0x1a0/0x660)
          [   75.762238]  r8:00000000 r7:00000003 r6:9dce9c10 r5:81203048 r4:9dce9c1c
          [   75.767655] [<806abb0c>] (dsa_switch_event) from [<80138e98>] (notifier_call_chain+0x54/0x94)
          [   75.774893]  r10:8125a0b4 r9:9dd1141c r8:00000000 r7:ffffffff r6:00000003 r5:9f54beb4
          [   75.781423]  r4:81203048
          [   75.782672] [<80138e44>] (notifier_call_chain) from [<801390bc>] (raw_notifier_call_chain+0x28/0x30)
          [   75.790514]  r9:00000000 r8:00000000 r7:9f72a300 r6:9dce9c54 r5:9ddc4000 r4:81203048
          [   75.796982] [<80139094>] (raw_notifier_call_chain) from [<806a9524>] (dsa_port_notify+0x24/0x38)
          [   75.804483] [<806a9500>] (dsa_port_notify) from [<806a9c7c>] (dsa_port_fdb_add+0x50/0x6c)
          [   75.811371] [<806a9c2c>] (dsa_port_fdb_add) from [<806ab228>] (dsa_slave_switchdev_event_work+0xb0/0x10c)
          [   75.819635]  r4:9ddffc00
          [   75.820885] [<806ab178>] (dsa_slave_switchdev_event_work) from [<80131e30>] (process_one_work+0x120/0x3a4)
          [   75.829241]  r6:9f40d200 r5:9f4c1900 r4:9ddffc00 r3:806ab178
          [   75.833612] [<80131d10>] (process_one_work) from [<80132124>] (worker_thread+0x70/0x574)
          [   75.840415]  r10:9f4c1900 r9:9f40d200 r8:9f54a038 r7:9f40d214 r6:812119a0 r5:9f4c1918
          [   75.846945]  r4:9f40d200
          [   75.848191] [<801320b4>] (worker_thread) from [<80137ad0>] (kthread+0x130/0x160)
          [   75.854300]  r10:9f4f7e88 r9:9f5f2dd8 r8:801320b4 r7:9f4c1900 r6:00000000 r5:9f53dbc0
          [   75.860830]  r4:9f5f2dc0
          [   75.862076] [<801379a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
          [   75.867999] Exception stack(0x9f54bfb0 to 0x9f54bff8)
          [   75.871753] bfa0:                                     00000000 00000000 00000000 00000000
          [   75.878640] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          [   75.885519] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
          [   75.890844]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801379a0
          [   75.897377]  r4:9f53dbc0 r3:9f54a000
          [   75.899663] Code: e3a02000 e3a03000 e14b26f4 e24bc055 (e5973000)
          [   75.904575] ---[ end trace fbca818a124dbf0d ]---
      
      Fixes: 816a3bed ("switchdev: Add fdb.added_by_user to switchdev notifications")
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a37fb855
  28. 04 5月, 2018 1 次提交