1. 28 Jan, 2021 2 commits
    • Vadim Fedorenko's avatar
      net: decnet: fix netdev refcount leaking on error path · 3f96d644
      Vadim Fedorenko authored
      On building the route there is an assumption that the destination
      could be local. In this case loopback_dev is used to get the address.
      If the address is still cannot be retrieved dn_route_output_slow
      returns EADDRNOTAVAIL with loopback_dev reference taken.
      
      Cannot find hash for the fixes tag because this code was introduced
      long time ago. I don't think that this bug has ever fired but the
      patch is done just to have a consistent code base.
      Signed-off-by: default avatarVadim Fedorenko <vfedorenko@novek.ru>
      Link: https://lore.kernel.org/r/1611619334-20955-1-git-send-email-vfedorenko@novek.ruSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3f96d644
    • Rasmus Villemoes's avatar
      net: switchdev: don't set port_obj_info->handled true when -EOPNOTSUPP · 20776b46
      Rasmus Villemoes authored
      It's not true that switchdev_port_obj_notify() only inspects the
      ->handled field of "struct switchdev_notifier_port_obj_info" if
      call_switchdev_blocking_notifiers() returns 0 - there's a WARN_ON()
      triggering for a non-zero return combined with ->handled not being
      true. But the real problem here is that -EOPNOTSUPP is not being
      properly handled.
      
      The wrapper functions switchdev_handle_port_obj_add() et al change a
      return value of -EOPNOTSUPP to 0, and the treatment of ->handled in
      switchdev_port_obj_notify() seems to be designed to change that back
      to -EOPNOTSUPP in case nobody actually acted on the notifier (i.e.,
      everybody returned -EOPNOTSUPP).
      
      Currently, as soon as some device down the stack passes the check_cb()
      check, ->handled gets set to true, which means that
      switchdev_port_obj_notify() cannot actually ever return -EOPNOTSUPP.
      
      This, for example, means that the detection of hardware offload
      support in the MRP code is broken: switchdev_port_obj_add() used by
      br_mrp_switchdev_send_ring_test() always returns 0, so since the MRP
      code thinks the generation of MRP test frames has been offloaded, no
      such frames are actually put on the wire. Similarly,
      br_mrp_switchdev_set_ring_role() also always returns 0, causing
      mrp->ring_role_offloaded to be set to 1.
      
      To fix this, continue to set ->handled true if any callback returns
      success or any error distinct from -EOPNOTSUPP. But if all the
      callbacks return -EOPNOTSUPP, make sure that ->handled stays false, so
      the logic in switchdev_port_obj_notify() can propagate that
      information.
      
      Fixes: 9a9f26e8 ("bridge: mrp: Connect MRP API with the switchdev API")
      Fixes: f30f0601 ("switchdev: Add helpers to aid traversal through lower devices")
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Link: https://lore.kernel.org/r/20210125124116.102928-1-rasmus.villemoes@prevas.dkSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      20776b46
  2. 27 Jan, 2021 5 commits
    • Jakub Kicinski's avatar
      Merge branch 'net-fec-fix-temporary-rmii-clock-reset-on-link-up' · 2bd29748
      Jakub Kicinski authored
      Laurent Badel says:
      
      ====================
      net: fec: Fix temporary RMII clock reset on link up
      
      v2: fixed a compilation warning
      
      The FEC drivers performs a "hardware reset" of the MAC module when the
      link is reported to be up. This causes a short glitch in the RMII clock
      due to the hardware reset clearing the receive control register which
      controls the MII mode. It seems that some link partners do not tolerate
      this glitch, and invalidate the link, which leads to a never-ending loop
      of negotiation-link up-link down events.
      
      This was observed with the iMX28 Soc and LAN8720/LAN8742 PHYs, with two
      Intel adapters I218-LM and X722-DA2 as link partners, though a number of
      other link partners do not seem to mind the clock glitch. Changing the
      hardware reset to a software reset (clearing bit 1 of the ECR register)
      cured the issue.
      
      Attempts to optimize fec_restart() in order to minimize the duration of
      the glitch were unsuccessful. Furthermore manually producing the glitch by
      setting MII mode and then back to RMII in two consecutive instructions,
      resulting in a clock glitch <10us in duration, was enough to cause the
      partner to invalidate the link. This strongly suggests that the root cause
      of the link being dropped is indeed the change in clock frequency.
      
      In an effort to minimize changes to driver, the patch proposes to use
      soft reset only for tested SoCs (iMX28) and only if the link is up. This
      preserves hardware reset in other situations, which might be required for
      proper setup of the MAC.
      ====================
      
      Link: https://lore.kernel.org/r/20210125100745.5090-1-laurentbadel@eaton.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2bd29748
    • Laurent Badel's avatar
      net: fec: Fix temporary RMII clock reset on link up · c730ab42
      Laurent Badel authored
      fec_restart() does a hard reset of the MAC module when the link status
      changes to up. This temporarily resets the R_CNTRL register which controls
      the MII mode of the ENET_OUT clock. In the case of RMII, the clock
      frequency momentarily drops from 50MHz to 25MHz until the register is
      reconfigured. Some link partners do not tolerate this glitch and
      invalidate the link causing failure to establish a stable link when using
      PHY polling mode. Since as per IEEE802.3 the criteria for link validity
      are PHY-specific, what the partner should tolerate cannot be assumed, so
      avoid resetting the MII clock by using software reset instead of hardware
      reset when the link is up. This is generally relevant only if the SoC
      provides the clock to an external PHY and the PHY is configured for RMII.
      Signed-off-by: default avatarLaurent Badel <laurentbadel@eaton.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c730ab42
    • Xie He's avatar
      net: lapb: Add locking to the lapb module · b491e6a7
      Xie He authored
      In the lapb module, the timers may run concurrently with other code in
      this module, and there is currently no locking to prevent the code from
      racing on "struct lapb_cb". This patch adds locking to prevent racing.
      
      1. Add "spinlock_t lock" to "struct lapb_cb"; Add "spin_lock_bh" and
      "spin_unlock_bh" to APIs, timer functions and notifier functions.
      
      2. Add "bool t1timer_stop, t2timer_stop" to "struct lapb_cb" to make us
      able to ask running timers to abort; Modify "lapb_stop_t1timer" and
      "lapb_stop_t2timer" to make them able to abort running timers;
      Modify "lapb_t2timer_expiry" and "lapb_t1timer_expiry" to make them
      abort after they are stopped by "lapb_stop_t1timer", "lapb_stop_t2timer",
      and "lapb_start_t1timer", "lapb_start_t2timer".
      
      3. Let lapb_unregister wait for other API functions and running timers
      to stop.
      
      4. The lapb_device_event function calls lapb_disconnect_request. In
      order to avoid trying to hold the lock twice, add a new function named
      "__lapb_disconnect_request" which assumes the lock is held, and make
      it called by lapb_disconnect_request and lapb_device_event.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: Martin Schiller <ms@dev.tdt.de>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20210126040939.69995-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b491e6a7
    • Ivan Vecera's avatar
      team: protect features update by RCU to avoid deadlock · f0947d0d
      Ivan Vecera authored
      Function __team_compute_features() is protected by team->lock
      mutex when it is called from team_compute_features() used when
      features of an underlying device is changed. This causes
      a deadlock when NETDEV_FEAT_CHANGE notifier for underlying device
      is fired due to change propagated from team driver (e.g. MTU
      change). It's because callbacks like team_change_mtu() or
      team_vlan_rx_{add,del}_vid() protect their port list traversal
      by team->lock mutex.
      
      Example (r8169 case where this driver disables TSO for certain MTU
      values):
      ...
      [ 6391.348202]  __mutex_lock.isra.6+0x2d0/0x4a0
      [ 6391.358602]  team_device_event+0x9d/0x160 [team]
      [ 6391.363756]  notifier_call_chain+0x47/0x70
      [ 6391.368329]  netdev_update_features+0x56/0x60
      [ 6391.373207]  rtl8169_change_mtu+0x14/0x50 [r8169]
      [ 6391.378457]  dev_set_mtu_ext+0xe1/0x1d0
      [ 6391.387022]  dev_set_mtu+0x52/0x90
      [ 6391.390820]  team_change_mtu+0x64/0xf0 [team]
      [ 6391.395683]  dev_set_mtu_ext+0xe1/0x1d0
      [ 6391.399963]  do_setlink+0x231/0xf50
      ...
      
      In fact team_compute_features() called from team_device_event()
      does not need to be protected by team->lock mutex and rcu_read_lock()
      is sufficient there for port list traversal.
      
      Fixes: 3d249d4c ("net: introduce ethernet teaming device")
      Cc: Saeed Mahameed <saeed@kernel.org>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Reviewed-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Link: https://lore.kernel.org/r/20210125074416.4056484-1-ivecera@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f0947d0d
    • Jakub Kicinski's avatar
      MAINTAINERS: add David Ahern to IPv4/IPv6 maintainers · 5cfeb562
      Jakub Kicinski authored
      David has been the de-facto maintainer for much of the IP code
      for the last couple of years, let's make it official.
      
      Link: https://lore.kernel.org/r/20210122173220.3579491-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5cfeb562
  3. 26 Jan, 2021 6 commits
  4. 25 Jan, 2021 21 commits
  5. 24 Jan, 2021 2 commits
  6. 23 Jan, 2021 4 commits