1. 28 Jan, 2021 7 commits
  2. 27 Jan, 2021 6 commits
    • Dan Carpenter's avatar
      can: dev: prevent potential information leak in can_fill_info() · b552766c
      Dan Carpenter authored
      The "bec" struct isn't necessarily always initialized. For example, the
      mcp251xfd_get_berr_counter() function doesn't initialize anything if the
      interface is down.
      
      Fixes: 52c793f2 ("can: netlink support for bus-error reporting and counters")
      Link: https://lore.kernel.org/r/YAkaRdRJncsJO8Ve@mwandaSigned-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      b552766c
    • 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 13 commits
  4. 25 Jan, 2021 14 commits