Skip to content
Snippets Groups Projects
  1. Mar 30, 2021
  2. Mar 29, 2021
    • Petr Machata's avatar
      nexthop: Rename artifacts related to legacy multipath nexthop groups · de1d1ee3
      Petr Machata authored
      
      After resilient next-hop groups have been added recently, there are two
      types of multipath next-hop groups: the legacy "mpath", and the new
      "resilient". Calling the legacy next-hop group type "mpath" is unfortunate,
      because that describes the fact that a packet could be forwarded in one of
      several paths, which is also true for the resilient next-hop groups.
      
      Therefore, to make the naming clearer, rename various artifacts to reflect
      the assumptions made. Therefore as of this patch:
      
      - The flag for multipath groups is nh_grp_entry::is_multipath. This
        includes the legacy and resilient groups, as well as any future group
        types that behave as multipath groups.
        Functions that assume this have "mpath" in the name.
      
      - The flag for legacy multipath groups is nh_grp_entry::hash_threshold.
        Functions that assume this have "hthr" in the name.
      
      - The flag for resilient groups is nh_grp_entry::resilient.
        Functions that assume this have "res" in the name.
      
      Besides the above, struct nh_grp_entry::mpath was renamed to ::hthr as
      well.
      
      UAPI artifacts were obviously left intact.
      
      Suggested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de1d1ee3
  3. Mar 26, 2021
  4. Mar 24, 2021
  5. Mar 23, 2021
    • 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
    • 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
  6. Mar 19, 2021
  7. Mar 18, 2021
  8. Mar 17, 2021
  9. Mar 16, 2021
    • Martin Willi's avatar
      can: dev: Move device back to init netns on owning netns delete · 3a5ca857
      Martin Willi authored
      When a non-initial netns is destroyed, the usual policy is to delete
      all virtual network interfaces contained, but move physical interfaces
      back to the initial netns. This keeps the physical interface visible
      on the system.
      
      CAN devices are somewhat special, as they define rtnl_link_ops even
      if they are physical devices. If a CAN interface is moved into a
      non-initial netns, destroying that netns lets the interface vanish
      instead of moving it back to the initial netns. default_device_exit()
      skips CAN interfaces due to having rtnl_link_ops set. Reproducer:
      
        ip netns add foo
        ip link set can0 netns foo
        ip netns delete foo
      
      WARNING: CPU: 1 PID: 84 at net/core/dev.c:11030 ops_exit_list+0x38/0x60
      CPU: 1 PID: 84 Comm: kworker/u4:2 Not tainted 5.10.19 #1
      Workqueue: netns cleanup_net
      [<c010e700>] (unwind_backtrace) from [<c010a1d8>] (show_stack+0x10/0x14)
      [<c010a1d8>] (show_stack) from [<c086dc10>] (dump_stack+0x94/0xa8)
      [<c086dc10>] (dump_stack) from [<c086b938>] (__warn+0xb8/0x114)
      [<c086b938>] (__warn) from [<c086ba10>] (warn_slowpath_fmt+0x7c/0xac)
      [<c086ba10>] (warn_slowpath_fmt) from [<c0629f20>] (ops_exit_list+0x38/0x60)
      [<c0629f20>] (ops_exit_list) from [<c062a5c4>] (cleanup_net+0x230/0x380)
      [<c062a5c4>] (cleanup_net) from [<c0142c20>] (process_one_work+0x1d8/0x438)
      [<c0142c20>] (process_one_work) from [<c0142ee4>] (worker_thread+0x64/0x5a8)
      [<c0142ee4>] (worker_thread) from [<c0148a98>] (kthread+0x148/0x14c)
      [<c0148a98>] (kthread) from [<c0100148>] (ret_from_fork+0x14/0x2c)
      
      To properly restore physical CAN devices to the initial netns on owning
      netns exit, introduce a flag on rtnl_link_ops that can be set by drivers.
      For CAN devices setting this flag, default_device_exit() considers them
      non-virtual, applying the usual namespace move.
      
      The issue was introduced in the commit mentioned below, as at that time
      CAN devices did not have a dellink() operation.
      
      Fixes: e008b5fc ("net: Simplfy default_device_exit and improve batching.")
      Link: https://lore.kernel.org/r/20210302122423.872326-1-martin@strongswan.org
      
      
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      3a5ca857
  10. Mar 15, 2021
  11. Mar 14, 2021
Loading