1. 23 Mar, 2021 10 commits
    • Vladimir Oltean's avatar
      net: dsa: pass extack to dsa_port_{bridge,lag}_join · 2afc526a
      Vladimir Oltean authored
      This is a pretty noisy change that was broken out of the larger change
      for replaying switchdev attributes and objects at bridge join time,
      which is when these extack objects are actually used.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2afc526a
    • Vladimir Oltean's avatar
      net: dsa: call dsa_port_bridge_join when joining a LAG that is already in a bridge · 185c9a76
      Vladimir Oltean authored
      DSA can properly detect and offload this sequence of operations:
      
      ip link add br0 type bridge
      ip link add bond0 type bond
      ip link set swp0 master bond0
      ip link set bond0 master br0
      
      But not this one:
      
      ip link add br0 type bridge
      ip link add bond0 type bond
      ip link set bond0 master br0
      ip link set swp0 master bond0
      
      Actually the second one is more complicated, due to the elapsed time
      between the enslavement of bond0 and the offloading of it via swp0, a
      lot of things could have happened to the bond0 bridge port in terms of
      switchdev objects (host MDBs, VLANs, altered STP state etc). So this is
      a bit of a can of worms, and making sure that the DSA port's state is in
      sync with this already existing bridge port is handled in the next
      patches.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      185c9a76
    • Vladimir Oltean's avatar
      net: bridge: add helper to replay VLANs installed on port · 22f67cdf
      Vladimir Oltean authored
      Currently this simple setup with DSA:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link add bond0 type bond
      ip link set bond0 master br0
      ip link set swp0 master bond0
      
      will not work because the bridge has created the PVID in br_add_if ->
      nbp_vlan_init, and it has notified switchdev of the existence of VLAN 1,
      but that was too early, since swp0 was not yet a lower of bond0, so it
      had no reason to act upon that notification.
      
      We need a helper in the bridge to replay the switchdev VLAN objects that
      were notified since the bridge port creation, because some of them may
      have been missed.
      
      As opposed to the br_mdb_replay function, the vg->vlan_list write side
      protection is offered by the rtnl_mutex which is sleepable, so we don't
      need to queue up the objects in atomic context, we can replay them right
      away.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22f67cdf
    • Vladimir Oltean's avatar
      net: bridge: add helper to replay port and local fdb entries · 04846f90
      Vladimir Oltean authored
      When a switchdev port starts offloading a LAG that is already in a
      bridge and has an FDB entry pointing to it:
      
      ip link set bond0 master br0
      bridge fdb add dev bond0 00:01:02:03:04:05 master static
      ip link set swp0 master bond0
      
      the switchdev driver will have no idea that this FDB entry is there,
      because it missed the switchdev event emitted at its creation.
      
      Ido Schimmel pointed this out during a discussion about challenges with
      switchdev offloading of stacked interfaces between the physical port and
      the bridge, and recommended to just catch that condition and deny the
      CHANGEUPPER event:
      https://lore.kernel.org/netdev/20210210105949.GB287766@shredder.lan/
      
      But in fact, we might need to deal with the hard thing anyway, which is
      to replay all FDB addresses relevant to this port, because it isn't just
      static FDB entries, but also local addresses (ones that are not
      forwarded but terminated by the bridge). There, we can't just say 'oh
      yeah, there was an upper already so I'm not joining that'.
      
      So, similar to the logic for replaying MDB entries, add a function that
      must be called by individual switchdev drivers and replays local FDB
      entries as well as ones pointing towards a bridge port. This time, we
      use the atomic switchdev notifier block, since that's what FDB entries
      expect for some reason.
      Reported-by: default avatarIdo Schimmel <idosch@idosch.org>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04846f90
    • Vladimir Oltean's avatar
      net: bridge: add helper to replay port and host-joined mdb entries · 4f2673b3
      Vladimir Oltean authored
      I have a system with DSA ports, and udhcpcd is configured to bring
      interfaces up as soon as they are created.
      
      I create a bridge as follows:
      
      ip link add br0 type bridge
      
      As soon as I create the bridge and udhcpcd brings it up, I also have
      avahi which automatically starts sending IPv6 packets to advertise some
      local services, and because of that, the br0 bridge joins the following
      IPv6 groups due to the code path detailed below:
      
      33:33:ff:6d:c1:9c vid 0
      33:33:00:00:00:6a vid 0
      33:33:00:00:00:fb vid 0
      
      br_dev_xmit
      -> br_multicast_rcv
         -> br_ip6_multicast_add_group
            -> __br_multicast_add_group
               -> br_multicast_host_join
                  -> br_mdb_notify
      
      This is all fine, but inside br_mdb_notify we have br_mdb_switchdev_host
      hooked up, and switchdev will attempt to offload the host joined groups
      to an empty list of ports. Of course nobody offloads them.
      
      Then when we add a port to br0:
      
      ip link set swp0 master br0
      
      the bridge doesn't replay the host-joined MDB entries from br_add_if,
      and eventually the host joined addresses expire, and a switchdev
      notification for deleting it is emitted, but surprise, the original
      addition was already completely missed.
      
      The strategy to address this problem is to replay the MDB entries (both
      the port ones and the host joined ones) when the new port joins the
      bridge, similar to what vxlan_fdb_replay does (in that case, its FDB can
      be populated and only then attached to a bridge that you offload).
      However there are 2 possibilities: the addresses can be 'pushed' by the
      bridge into the port, or the port can 'pull' them from the bridge.
      
      Considering that in the general case, the new port can be really late to
      the party, and there may have been many other switchdev ports that
      already received the initial notification, we would like to avoid
      delivering duplicate events to them, since they might misbehave. And
      currently, the bridge calls the entire switchdev notifier chain, whereas
      for replaying it should just call the notifier block of the new guy.
      But the bridge doesn't know what is the new guy's notifier block, it
      just knows where the switchdev notifier chain is. So for simplification,
      we make this a driver-initiated pull for now, and the notifier block is
      passed as an argument.
      
      To emulate the calling context for mdb objects (deferred and put on the
      blocking notifier chain), we must iterate under RCU protection through
      the bridge's mdb entries, queue them, and only call them once we're out
      of the RCU read-side critical section.
      
      There was some opportunity for reuse between br_mdb_switchdev_host_port,
      br_mdb_notify and the newly added br_mdb_queue_one in how the switchdev
      mdb object is created, so a helper was created.
      Suggested-by: default avatarIdo Schimmel <idosch@idosch.org>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f2673b3
    • Vladimir Oltean's avatar
      net: bridge: add helper to retrieve the current ageing time · f1d42ea1
      Vladimir Oltean authored
      The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
      
      sysfs/ioctl/netlink
      -> br_set_ageing_time
         -> __set_ageing_time
      
      therefore not at bridge port creation time, so:
      (a) switchdev drivers have to hardcode the initial value for the address
          ageing time, because they didn't get any notification
      (b) that hardcoded value can be out of sync, if the user changes the
          ageing time before enslaving the port to the bridge
      
      We need a helper in the bridge, such that switchdev drivers can query
      the current value of the bridge ageing time when they start offloading
      it.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1d42ea1
    • Vladimir Oltean's avatar
      net: bridge: add helper for retrieving the current bridge port STP state · c0e715bb
      Vladimir Oltean authored
      It may happen that we have the following topology with DSA or any other
      switchdev driver with LAG offload:
      
      ip link add br0 type bridge stp_state 1
      ip link add bond0 type bond
      ip link set bond0 master br0
      ip link set swp0 master bond0
      ip link set swp1 master bond0
      
      STP decides that it should put bond0 into the BLOCKING state, and
      that's that. The ports that are actively listening for the switchdev
      port attributes emitted for the bond0 bridge port (because they are
      offloading it) and have the honor of seeing that switchdev port
      attribute can react to it, so we can program swp0 and swp1 into the
      BLOCKING state.
      
      But if then we do:
      
      ip link set swp2 master bond0
      
      then as far as the bridge is concerned, nothing has changed: it still
      has one bridge port. But this new bridge port will not see any STP state
      change notification and will remain FORWARDING, which is how the
      standalone code leaves it in.
      
      We need a function in the bridge driver which retrieves the current STP
      state, such that drivers can synchronize to it when they may have missed
      switchdev events.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0e715bb
    • Xie He's avatar
      net: lapb: Make "lapb_t1timer_running" able to detect an already running timer · 65d2dbb3
      Xie He authored
      Problem:
      
      The "lapb_t1timer_running" function in "lapb_timer.c" is used in only
      one place: in the "lapb_kick" function in "lapb_out.c". "lapb_kick" calls
      "lapb_t1timer_running" to check if the timer is already pending, and if
      it is not, schedule it to run.
      
      However, if the timer has already fired and is running, and is waiting to
      get the "lapb->lock" lock, "lapb_t1timer_running" will not detect this,
      and "lapb_kick" will then schedule a new timer. The old timer will then
      abort when it sees a new timer pending.
      
      I think this is not right. The purpose of "lapb_kick" should be ensuring
      that the actual work of the timer function is scheduled to be done.
      If the timer function is already running but waiting for the lock,
      "lapb_kick" should not abort and reschedule it.
      
      Changes made:
      
      I added a new field "t1timer_running" in "struct lapb_cb" for
      "lapb_t1timer_running" to use. "t1timer_running" will accurately reflect
      whether the actual work of the timer is pending. If the timer has fired
      but is still waiting for the lock, "t1timer_running" will still correctly
      reflect whether the actual work is waiting to be done.
      
      The old "t1timer_stop" field, whose only responsibility is to ask a timer
      (that is already running but waiting for the lock) to abort, is no longer
      needed, because the new "t1timer_running" field can fully take over its
      responsibility. Therefore "t1timer_stop" is deleted.
      
      "t1timer_running" is not simply a negation of the old "t1timer_stop".
      At the end of the timer function, if it does not reschedule itself,
      "t1timer_running" is set to false to indicate that the timer is stopped.
      
      For consistency of the code, I also added "t2timer_running" and deleted
      "t2timer_stop".
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65d2dbb3
    • Kurt Kanzenbach's avatar
      net: dsa: hellcreek: Report switch name and ID · 1ab568e9
      Kurt Kanzenbach authored
      Report the driver name, ASIC ID and the switch name via devlink. This is a
      useful information for user space tooling.
      Signed-off-by: default avatarKurt Kanzenbach <kurt@kmk-computers.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ab568e9
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next · 9a255a06
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter updates for net-next
      
      The following batch contains Netfilter updates for net-next:
      
      1) Split flowtable workqueues per events, from Oz Shlomo.
      
      2) fall-through warnings for clang, from Gustavo A. R. Silva
      
      3) Remove unused declaration in conntrack, from YueHaibing.
      
      4) Consolidate skb_try_make_writable() in flowtable datapath,
         simplify some of the existing codebase.
      
      5) Call dst_check() to fall back to static classic forwarding path.
      
      6) Update table flags from commit phase.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a255a06
  2. 22 Mar, 2021 30 commits