From: Vladimir Oltean <olteanv@gmail.com>
To: "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"vladimir.oltean@nxp.com" <vladimir.oltean@nxp.com>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
"claudiu.manoil@nxp.com" <claudiu.manoil@nxp.com>,
"woojung.huh@microchip.com" <woojung.huh@microchip.com>,
"dqfext@gmail.com" <dqfext@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"george.mccollister@gmail.com" <george.mccollister@gmail.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"linux@rempel-privat.de" <linux@rempel-privat.de>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"hauke@hauke-m.de" <hauke@hauke-m.de>,
"LinoSanfilippo@gmx.de" <LinoSanfilippo@gmx.de>,
"kuba@kernel.org" <kuba@kernel.org>,
"sean.wang@mediatek.com" <sean.wang@mediatek.com>,
"kurt@linutronix.de" <kurt@linutronix.de>,
"m.grzeschik@pengutronix.de" <m.grzeschik@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"Landen.Chao@mediatek.com" <Landen.Chao@mediatek.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: Re: [PATCH v2 net 2/5] net: dsa: be compatible with masters which unregister on shutdown
Date: Fri, 13 Sep 2024 23:29:16 +0300 [thread overview]
Message-ID: <20240913202916.t7bpdc6ubfdpv47s@skbuf> (raw)
In-Reply-To: <2d2e3bba17203c14a5ffdabc174e3b6bbb9ad438.camel@siemens.com>
Hi Alexander,
On Wed, Sep 04, 2024 at 08:31:13AM +0000, Sverdlin, Alexander wrote:
> > +static void lan9303_mdio_shutdown(struct mdio_device *mdiodev)
> > +{
> > + struct lan9303_mdio *sw_dev = dev_get_drvdata(&mdiodev->dev);
> > +
> > + if (!sw_dev)
> > + return;
> > +
> > + lan9303_shutdown(&sw_dev->chip);
> > +
> > + dev_set_drvdata(&mdiodev->dev, NULL);
> > }
>
> This unfortunately didn't work well with LAN9303 and probably will not work
> with others:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> CPU: 0 PID: 442 Comm: kworker/0:3 Tainted: G O 6.1.99+gitb7793b7d9b35 #1
> Workqueue: events_power_efficient phy_state_machine
> pc : lan9303_mdio_phy_read+0x1c/0x34
> lr : lan9303_phy_read+0x50/0x100
> Call trace:
> lan9303_mdio_phy_read+0x1c/0x34
> lan9303_phy_read+0x50/0x100
> dsa_slave_phy_read+0x40/0x50
> __mdiobus_read+0x34/0x130
> mdiobus_read+0x44/0x70
> genphy_update_link+0x2c/0x104
> genphy_read_status+0x2c/0x120
> phy_check_link_status+0xb8/0xcc
> phy_state_machine+0x198/0x27c
> process_one_work+0x1dc/0x450
> worker_thread+0x154/0x450
>
> as long as the ports are not down (and dsa_switch_shutdown() doesn't ensure it),
> we cannot just zero drvdata, because PHY polling will eventually call
>
> static int lan9303_mdio_phy_read(struct lan9303 *chip, int addr, int reg)
> {
> struct lan9303_mdio *sw_dev = dev_get_drvdata(chip->dev);
>
> return mdiobus_read_nested(sw_dev->device->bus, addr, reg);
>
> There are however multiple other unsafe patterns.
> I suppose current
>
> dsa_switch_shutdown();
> dev_set_drvdata(...->dev, NULL);
>
> pattern is broken in many cases...
Unfortunately the code portion which you've quoted for your reply does not
show the full story. dsa_switch_shutdown(), at the time of this patch,
was implemented like this (stripped of comments):
void dsa_switch_shutdown(struct dsa_switch *ds)
{
struct net_device *master, *slave_dev;
LIST_HEAD(unregister_list);
struct dsa_port *dp;
mutex_lock(&dsa2_mutex);
rtnl_lock();
list_for_each_entry(dp, &ds->dst->ports, list) {
if (dp->ds != ds)
continue;
if (!dsa_port_is_user(dp))
continue;
master = dp->cpu_dp->master;
slave_dev = dp->slave;
netdev_upper_dev_unlink(master, slave_dev);
unregister_netdevice_queue(slave_dev, &unregister_list);
}
unregister_netdevice_many(&unregister_list);
rtnl_unlock();
mutex_unlock(&dsa2_mutex);
}
I believe you would be wrong to blame this patch for exiting with the
slave/user ports still running (and thus ds->ops->phy_read() still
callable), because, as you can see, it doesn't do that - it unregisters
them, which also stops the net_device prior. So, both phylink_stop() and
phylink_destroy() would be called.
The patch had other problems though, and that led to the rework in
commit ee534378f005 ("net: dsa: fix panic when DSA master device unbinds
on shutdown"), rework which is in fact to blame for what you're reporting.
Given that we are talking about a fix to a fix, it doesn't really matter
in terms of backporting targets which one it is, but for correctness sake,
it is the later patch that fixed some things while introducing the race
condition.
next prev parent reply other threads:[~2024-09-13 20:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 13:34 [PATCH v2 net 0/5] Make DSA switch drivers compatible with masters which unregister on shutdown Vladimir Oltean
2021-09-17 13:34 ` [PATCH v2 net 1/5] net: mdio: introduce a shutdown method to mdio device drivers Vladimir Oltean
2021-09-17 13:34 ` [PATCH v2 net 2/5] net: dsa: be compatible with masters which unregister on shutdown Vladimir Oltean
2024-09-04 8:31 ` Sverdlin, Alexander
2024-09-13 20:29 ` Vladimir Oltean [this message]
2021-09-17 13:34 ` [PATCH v2 net 3/5] net: dsa: hellcreek: " Vladimir Oltean
2021-09-17 13:34 ` [PATCH v2 net 4/5] net: dsa: microchip: ksz8863: " Vladimir Oltean
2021-09-17 13:34 ` [PATCH v2 net 5/5] net: dsa: xrs700x: " Vladimir Oltean
2021-09-19 11:20 ` [PATCH v2 net 0/5] Make DSA switch drivers " 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=20240913202916.t7bpdc6ubfdpv47s@skbuf \
--to=olteanv@gmail.com \
--cc=Landen.Chao@mediatek.com \
--cc=LinoSanfilippo@gmx.de \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexander.sverdlin@siemens.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--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=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rempel-privat.de \
--cc=m.grzeschik@pengutronix.de \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox