All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org
Subject: [PATCH RFC 0/4] Fixes for Marvell MII paged register access races
Date: Fri, 8 Dec 2017 15:47:57 +0000	[thread overview]
Message-ID: <20171208154756.GF10595@n2100.armlinux.org.uk> (raw)

Hi,

While doing final testing of the mvneta changes for phylink, a very
easy to trigger race condition was found with the Marvell PHY driver
which manifested itself as the link going down when a hibernate cycle
terminates.

The issue turned out to be a race between two threads accessing the
PHY - one trying to do a status read and the other configuring the PHY.

The result is the configuration thread tries to read-modify-write a
paged register in a non-copper page, but the status read thread
switches the PHY back to the copper page half-way through.

Various solutions involving phy->lock were considered, but found to
create more lock dependency issues than were nice to deal with.

The solution proposed here uses the mdiobus lock to ensure that accesses
to paged registers become atomic with respect to all other bus accesses,
including those from userspace.

There is an open question whether there should be generic helpers for
this.  Generic helpers would mean:

- Additional couple of function pointers in phy_driver to read/write the
  paging register.  This has the restriction that there must only be one
  paging register.

- The helpers become more expensive, and because they're in a separate
  compilation unit, the compiler will be unable to optimise them by
  inlining the static functions.

- The helpers would be re-usable, saving replications of that code, and
  making it more likely for phy authors to safely access the PHY.

Another potential question is whether using the mdiobus lock (which
excludes all other MII bus access) is best - while it has the advantage
of also ensuring atomicity with userspace accesses, it means that no one
else can access an independent PHY on the same bus while a paged access
is on-going.  It feels like a big hammer, but I'm not convinced that we
will see a lot of contention on it.

Comments?

 drivers/net/phy/marvell.c  | 365 +++++++++++++++++++++------------------------
 drivers/net/phy/mdio_bus.c |  65 ++++++--
 drivers/net/phy/phy-core.c |  11 +-
 include/linux/mdio.h       |   3 +
 include/linux/phy.h        |  26 ++++
 5 files changed, 256 insertions(+), 214 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

             reply	other threads:[~2017-12-08 15:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 15:47 Russell King - ARM Linux [this message]
2017-12-08 15:48 ` [PATCH RFC 1/4] net: mdiobus: add unlocked accessors Russell King
2017-12-09 18:20   ` Florian Fainelli
2017-12-08 15:48 ` [PATCH RFC 2/4] net: phy: use unlocked accessors for indirect MMD accesses Russell King
2017-12-09 18:21   ` Florian Fainelli
2017-12-08 15:48 ` [PATCH RFC 3/4] net: phy: add unlocked accessors Russell King
2017-12-09 18:22   ` Florian Fainelli
2017-12-09 23:11     ` Russell King - ARM Linux
2017-12-08 15:48 ` [PATCH RFC 4/4] net: phy: marvell: fix paged access races Russell King
2017-12-08 16:17 ` [PATCH RFC 0/4] Fixes for Marvell MII paged register " Andrew Lunn
2017-12-08 16:44   ` Russell King - ARM Linux
2017-12-09 18:22     ` Florian Fainelli
2017-12-09 23:49       ` Russell King - ARM Linux
2017-12-10  0:19         ` Andrew Lunn
2017-12-09 18:19 ` Florian Fainelli
2017-12-09 19:06   ` Andrew Lunn

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=20171208154756.GF10595@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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.