All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	UNGLinuxDriver@microchip.com, "DENG Qingfang" <dqfext@gmail.com>,
	"Kurt Kanzenbach" <kurt@linutronix.de>,
	"Hauke Mehrtens" <hauke@hauke-m.de>,
	"Woojung Huh" <woojung.huh@microchip.com>,
	"Sean Wang" <sean.wang@mediatek.com>,
	"Landen Chao" <Landen.Chao@mediatek.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"George McCollister" <george.mccollister@gmail.com>,
	"John Crispin" <john@phrozen.org>,
	"Aleksander Jan Bajkowski" <olek2@wp.pl>,
	"Egil Hjelmeland" <privat@egil-hjelmeland.no>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Prasanna Vengateshan" <prasanna.vengateshan@microchip.com>,
	"Ansuel Smith" <ansuelsmth@gmail.com>,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"Claudiu Manoil" <claudiu.manoil@nxp.com>
Subject: [PATCH v5 net-next 00/10] Drop rtnl_lock from DSA .port_fdb_{add,del}
Date: Sun, 24 Oct 2021 20:17:47 +0300	[thread overview]
Message-ID: <20211024171757.3753288-1-vladimir.oltean@nxp.com> (raw)

As mentioned in the RFC posted 2 months ago:
https://patchwork.kernel.org/project/netdevbpf/cover/20210824114049.3814660-1-vladimir.oltean@nxp.com/

DSA is transitioning to a driver API where the rtnl_lock is not held
when calling ds->ops->port_fdb_add() and ds->ops->port_fdb_del().
Drivers cannot take that lock privately from those callbacks either.

This change is required so that DSA can wait for switchdev FDB work
items to finish before leaving the bridge. That change will be made in a
future patch series.

A small selftest is provided with the patch set in the hope that
concurrency issues uncovered by this series, but not spotted by me by
code inspection, will be caught.

A status of the existing drivers:

- mv88e6xxx_port_fdb_add() and mv88e6xxx_port_fdb_del() take
  mv88e6xxx_reg_lock() so they should be safe.

- qca8k_fdb_add() and qca8k_fdb_del() take mutex_lock(&priv->reg_mutex)
  so they should be safe.

- hellcreek_fdb_add() and hellcreek_fdb_add() take mutex_lock(&hellcreek->reg_lock)
  so they should be safe.

- ksz9477_port_fdb_add() and ksz9477_port_fdb_del() take mutex_lock(&dev->alu_mutex)
  so they should be safe.

- b53_fdb_add() and b53_fdb_del() did not have locking, so I've added a
  scheme based on my own judgement there (not tested).

- felix_fdb_add() and felix_fdb_del() did not have locking, I've added
  and tested a locking scheme there.

- mt7530_port_fdb_add() and mt7530_port_fdb_del() take
  mutex_lock(&priv->reg_mutex), so they should be safe.

- gswip_port_fdb() did not have locking, so I've added a non-expert
  locking scheme based on my own judgement (not tested).

- lan9303_alr_add_port() and lan9303_alr_del_port() take
  mutex_lock(&chip->alr_mutex) so they should be safe.

- sja1105_fdb_add() and sja1105_fdb_del() did not have locking, I've
  added and tested a locking scheme.

Changes in v3:
Unlock arl_mutex only once in b53_fdb_dump().

Changes in v4:
- Use __must_hold in ocelot and b53
- Add missing mutex_init in lantiq_gswip
- Clean up the selftest a bit.

Changes in v5:
- Replace __must_hold with a comment.
- Add a new patch (01/10).

Vladimir Oltean (10):
  net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns
    error
  net: dsa: sja1105: wait for dynamic config command completion on
    writes too
  net: dsa: sja1105: serialize access to the dynamic config interface
  net: mscc: ocelot: serialize access to the MAC table
  net: dsa: b53: serialize access to the ARL table
  net: dsa: lantiq_gswip: serialize access to the PCE registers
  net: dsa: introduce locking for the address lists on CPU and DSA ports
  net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work
  selftests: lib: forwarding: allow tests to not require mz and jq
  selftests: net: dsa: add a stress test for unlocked FDB operations

 MAINTAINERS                                   |  1 +
 drivers/net/dsa/b53/b53_common.c              | 36 ++++++--
 drivers/net/dsa/b53/b53_priv.h                |  1 +
 drivers/net/dsa/lantiq_gswip.c                | 28 +++++-
 drivers/net/dsa/sja1105/sja1105.h             |  2 +
 .../net/dsa/sja1105/sja1105_dynamic_config.c  | 91 ++++++++++++++-----
 drivers/net/dsa/sja1105/sja1105_main.c        |  1 +
 drivers/net/ethernet/mscc/ocelot.c            | 53 ++++++++---
 include/net/dsa.h                             |  1 +
 include/soc/mscc/ocelot.h                     |  3 +
 net/dsa/dsa2.c                                |  1 +
 net/dsa/slave.c                               |  2 -
 net/dsa/switch.c                              | 80 ++++++++++------
 .../drivers/net/dsa/test_bridge_fdb_stress.sh | 47 ++++++++++
 tools/testing/selftests/net/forwarding/lib.sh | 10 +-
 15 files changed, 280 insertions(+), 77 deletions(-)
 create mode 100755 tools/testing/selftests/drivers/net/dsa/test_bridge_fdb_stress.sh

-- 
2.25.1


             reply	other threads:[~2021-10-24 17:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-24 17:17 Vladimir Oltean [this message]
2021-10-24 17:17 ` [PATCH v5 net-next 01/10] net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns error Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 02/10] net: dsa: sja1105: wait for dynamic config command completion on writes too Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 03/10] net: dsa: sja1105: serialize access to the dynamic config interface Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 04/10] net: mscc: ocelot: serialize access to the MAC table Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 05/10] net: dsa: b53: serialize access to the ARL table Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 06/10] net: dsa: lantiq_gswip: serialize access to the PCE registers Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 07/10] net: dsa: introduce locking for the address lists on CPU and DSA ports Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 08/10] net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work Vladimir Oltean
2021-10-24 17:17 ` [PATCH v5 net-next 09/10] selftests: lib: forwarding: allow tests to not require mz and jq Vladimir Oltean
2021-10-25  6:36   ` Ido Schimmel
2021-10-24 17:17 ` [PATCH v5 net-next 10/10] selftests: net: dsa: add a stress test for unlocked FDB operations Vladimir Oltean
2021-10-25 12:10 ` [PATCH v5 net-next 00/10] Drop rtnl_lock from DSA .port_fdb_{add,del} patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211024171757.3753288-1-vladimir.oltean@nxp.com \
    --to=vladimir.oltean@nxp.com \
    --cc=Landen.Chao@mediatek.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=george.mccollister@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olek2@wp.pl \
    --cc=olteanv@gmail.com \
    --cc=prasanna.vengateshan@microchip.com \
    --cc=privat@egil-hjelmeland.no \
    --cc=sean.wang@mediatek.com \
    --cc=vivien.didelot@gmail.com \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.