1. 25 Oct, 2021 9 commits
    • Vladimir Oltean's avatar
      net: dsa: introduce locking for the address lists on CPU and DSA ports · 338a3a47
      Vladimir Oltean authored
      Now that the rtnl_mutex is going away for dsa_port_{host_,}fdb_{add,del},
      no one is serializing access to the address lists that DSA keeps for the
      purpose of reference counting on shared ports (CPU and cascade ports).
      
      It can happen for one dsa_switch_do_fdb_del to do list_del on a dp->fdbs
      element while another dsa_switch_do_fdb_{add,del} is traversing dp->fdbs.
      We need to avoid that.
      
      Currently dp->mdbs is not at risk, because dsa_switch_do_mdb_{add,del}
      still runs under the rtnl_mutex. But it would be nice if it would not
      depend on that being the case. So let's introduce a mutex per port (the
      address lists are per port too) and share it between dp->mdbs and
      dp->fdbs.
      
      The place where we put the locking is interesting. It could be tempting
      to put a DSA-level lock which still serializes calls to
      .port_fdb_{add,del}, but it would still not avoid concurrency with other
      driver code paths that are currently under rtnl_mutex (.port_fdb_dump,
      .port_fast_age). So it would add a very false sense of security (and
      adding a global switch-wide lock in DSA to resynchronize with the
      rtnl_lock is also counterproductive and hard).
      
      So the locking is intentionally done only where the dp->fdbs and dp->mdbs
      lists are traversed. That means, from a driver perspective, that
      .port_fdb_add will be called with the dp->addr_lists_lock mutex held on
      the CPU port, but not held on user ports. This is done so that driver
      writers are not encouraged to rely on any guarantee offered by
      dp->addr_lists_lock.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      338a3a47
    • Vladimir Oltean's avatar
      net: dsa: lantiq_gswip: serialize access to the PCE registers · cf231b43
      Vladimir Oltean authored
      The GSWIP switch accesses various bridging layer tables (VLANs, FDBs,
      forwarding rules) indirectly through PCE registers. These hardware
      accesses are non-atomic, being comprised of several register reads and
      writes.
      
      These accesses are currently serialized by the rtnl_lock, but DSA is
      changing its driver API and that lock will no longer be held when
      calling ->port_fdb_add() and ->port_fdb_del().
      
      So this driver needs to serialize the access to the PCE registers using
      its own locking scheme. This patch adds that.
      
      Note that the driver also uses the gswip_pce_load_microcode() function
      to load a static configuration for the packet classification engine into
      a table using the same registers. It is currently not protected, but
      since that configuration is only done from the dsa_switch_ops :: setup
      method, there is no risk of it being concurrent with other operations.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf231b43
    • Vladimir Oltean's avatar
      net: dsa: b53: serialize access to the ARL table · f7eb4a1c
      Vladimir Oltean authored
      The b53 driver performs non-atomic transactions to the ARL table when
      adding, deleting and reading FDB and MDB entries.
      
      Traditionally these were all serialized by the rtnl_lock(), but now it
      is possible that DSA calls ->port_fdb_add and ->port_fdb_del without
      holding that lock.
      
      So the driver must have its own serialization logic. Add a mutex and
      hold it from all entry points (->port_fdb_{add,del,dump},
      ->port_mdb_{add,del}).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7eb4a1c
    • Vladimir Oltean's avatar
      net: mscc: ocelot: serialize access to the MAC table · 2468346c
      Vladimir Oltean authored
      DSA would like to remove the rtnl_lock from its
      SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE handlers, and the felix driver uses
      the same MAC table functions as ocelot.
      
      This means that the MAC table functions will no longer be implicitly
      serialized with respect to each other by the rtnl_mutex, we need to add
      a dedicated lock in ocelot for the non-atomic operations of selecting a
      MAC table row, reading/writing what we want and polling for completion.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2468346c
    • Vladimir Oltean's avatar
      net: dsa: sja1105: serialize access to the dynamic config interface · eb016afd
      Vladimir Oltean authored
      The sja1105 hardware seems as concurrent as can be, but when we create a
      background script that adds/removes a rain of FDB entries without the
      rtnl_mutex taken, then in parallel we do another operation like run
      'bridge fdb show', we can notice these errors popping up:
      
      sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:40 vid 0: -ENOENT
      sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:40 vid 0 to fdb: -2
      sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:46 vid 0: -ENOENT
      sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:46 vid 0 to fdb: -2
      
      Luckily what is going on does not require a major rework in the driver.
      The sja1105_dynamic_config_read() function sends multiple SPI buffers to
      the peripheral until the operation completes. We should not do anything
      until the hardware clears the VALID bit.
      
      But since there is no locking (i.e. right now we are implicitly
      serialized by the rtnl_mutex, but if we remove that), it might be
      possible that the process which performs the dynamic config read is
      preempted and another one performs a dynamic config write.
      
      What will happen in that case is that sja1105_dynamic_config_read(),
      when it resumes, expects to see VALIDENT set for the entry it reads
      back. But it won't.
      
      This can be corrected by introducing a mutex for serializing SPI
      accesses to the dynamic config interface which should be atomic with
      respect to each other.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb016afd
    • Vladimir Oltean's avatar
      net: dsa: sja1105: wait for dynamic config command completion on writes too · df405910
      Vladimir Oltean authored
      The hardware manual says that software should attempt a new dynamic
      config access (be it a a write or a read-back) only while the VALID bit
      is cleared. The VALID bit is set by software to 1, and it remains set as
      long as the hardware is still processing the request.
      
      Currently the driver only polls for the command completion only for
      reads, because that's when we need the actual data read back. Writes
      have been more or less "asynchronous", although this has never been an
      observable issue.
      
      This change makes sja1105_dynamic_config_write poll the VALID bit as
      well, to absolutely ensure that a follow-up access to the static config
      finds the VALID bit cleared.
      
      So VALID means "work in progress", while VALIDENT means "entry being
      read is valid". On reads we check the VALIDENT bit too, while on writes
      that bit is not always defined. So we need to factor it out of the loop,
      and make the loop provide back the unpacked command structure, so that
      sja1105_dynamic_config_read can check the VALIDENT bit.
      
      The change also attempts to convert the open-coded loop to use the
      read_poll_timeout macro, since I know this will come up during review.
      It's more code, but hey, it uses read_poll_timeout!
      
      Tested on SJA1105T, SJA1105S, SJA1110A.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df405910
    • Vladimir Oltean's avatar
      net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns error · 232deb3f
      Vladimir Oltean authored
      At present, when either of ds->ops->port_fdb_del() or ds->ops->port_mdb_del()
      return a non-zero error code, we attempt to save the day and keep the
      data structure associated with that switchdev object, as the deletion
      procedure did not complete.
      
      However, the way in which we do this is suspicious to the checker in
      lib/refcount.c, who thinks it is buggy to increment a refcount that
      became zero, and that this is indicative of a use-after-free.
      
      Fixes: 161ca59d ("net: dsa: reference count the MDB entries at the cross-chip notifier level")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      232deb3f
    • David S. Miller's avatar
      Revert "Merge branch 'dsa-rtnl'" · 2d7e73f0
      David S. Miller authored
      This reverts commit 965e6b26, reversing
      changes made to 4d98bb0d.
      2d7e73f0
    • David S. Miller's avatar
      Merge tag 'linux-can-next-for-5.16-20211024' of... · 12f241f2
      David S. Miller authored
      Merge tag 'linux-can-next-for-5.16-20211024' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can-next 2021-10-24
      
      this is a pull request of 15 patches for net-next/master.
      
      The first patch is by Thomas Gleixner and makes use of
      hrtimer_forward_now() in the CAN broad cast manager (bcm).
      
      The next patch is by me and changes the type of the variables used in
      the CAN bit timing calculation can_fixup_bittiming() to unsigned int.
      
      Vincent Mailhol provides 6 patches targeting the CAN device
      infrastructure. The CAN-FD specific Transmitter Delay Compensation
      (TDC) is updated and configuration via the CAN netlink interface is
      added.
      
      Qing Wang's patch updates the at91 and janz-ican3 drivers to use
      sysfs_emit() instead of snprintf() in the sysfs show functions.
      
      Geert Uytterhoeven's patch drops the unneeded ARM dependency from the
      rar Kconfig.
      
      Cai Huoqing's patch converts the mscan driver to make use of the
      dev_err_probe() helper function.
      
      A patch by me against the gsusb driver changes the printf format
      strings to use %u to print unsigned values.
      
      Stephane Grosjean's patch updates the peak_usb CAN-FD driver to use
      the 64 bit timestamps provided by the hardware.
      
      The last 2 patches target the xilinx_can driver. Michal Simek provides
      a patch that removes repeated word from the kernel-doc and Dongliang
      Mu's patch removes a redundant netif_napi_del() from the xcan_remove()
      function.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12f241f2
  2. 24 Oct, 2021 31 commits