* [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path
@ 2026-09-23 8:40 Ginger Li
2026-09-23 18:47 ` Markus Elfring
2026-09-23 18:55 ` Andrew Lunn
0 siblings, 2 replies; 3+ messages in thread
From: Ginger Li @ 2026-09-23 8:40 UTC (permalink / raw)
To: netdev; +Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-kernel
dm9000_timeout() takes db->lock with interrupts disabled and then calls
dm9000_init_dm9000(), which expects the caller to hold that lock and accesses
the chip registers directly. For DM9000B devices dm9000_init_dm9000() also
calls dm9000_phy_write(), and that function takes db->lock again, so the TX
timeout path deadlocks on the same CPU.
dm9000_phy_write() already skips db->addr_lock when db->in_timeout is set,
because in that case the caller holds db->lock and sleeping is not allowed
either. Skip db->lock as well then, so that the nested call from
dm9000_init_dm9000() works as intended.
Fixes: 6741f40 ("DM9000B: driver initialization upgrade")
Signed-off-by: Ginger Li <ginger.jzllee@gmail.com>
---
drivers/net/ethernet/davicom/dm9000.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -325,10 +325,10 @@ dm9000_phy_write(struct net_device *dev,
unsigned long reg_save;
dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
- if (!db->in_timeout)
+ if (!db->in_timeout) {
mutex_lock(&db->addr_lock);
-
- spin_lock_irqsave(&db->lock, flags);
+ spin_lock_irqsave(&db->lock, flags);
+ }
/* Save previous register address */
reg_save = readb(db->io_addr);
@@ -344,11 +344,14 @@ dm9000_phy_write(struct net_device *dev,
iow(db, DM9000_EPCR, EPCR_EPOS | EPCR_ERPRW);
writeb(reg_save, db->io_addr);
- spin_unlock_irqrestore(&db->lock, flags);
+ if (!db->in_timeout)
+ spin_unlock_irqrestore(&db->lock, flags);
dm9000_msleep(db, 1); /* Wait write complete */
- spin_lock_irqsave(&db->lock, flags);
+ if (!db->in_timeout)
+ spin_lock_irqsave(&db->lock, flags);
+
reg_save = readb(db->io_addr);
iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer write command */
@@ -356,9 +359,10 @@ dm9000_phy_write(struct net_device *dev,
/* restore the previous address */
writeb(reg_save, db->io_addr);
- spin_unlock_irqrestore(&db->lock, flags);
- if (!db->in_timeout)
+ if (!db->in_timeout) {
+ spin_unlock_irqrestore(&db->lock, flags);
mutex_unlock(&db->addr_lock);
+ }
}
/* dm9000_set_io
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path
2026-09-23 8:40 [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path Ginger Li
@ 2026-09-23 18:47 ` Markus Elfring
2026-09-23 18:55 ` Andrew Lunn
1 sibling, 0 replies; 3+ messages in thread
From: Markus Elfring @ 2026-09-23 18:47 UTC (permalink / raw)
To: Ginger Li, netdev
Cc: LKML, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
…
> Fixes: 6741f40 ("DM9000B: driver initialization upgrade")
A longer hash would be preferred for such a tag.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.3-rc4#n157
Regards,
Markus
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path
2026-09-23 8:40 [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path Ginger Li
2026-09-23 18:47 ` Markus Elfring
@ 2026-09-23 18:55 ` Andrew Lunn
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Lunn @ 2026-09-23 18:55 UTC (permalink / raw)
To: Ginger Li
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni, linux-kernel
On Wed, Sep 23, 2026 at 04:40:55PM +0800, Ginger Li wrote:
> dm9000_timeout() takes db->lock with interrupts disabled and then calls
> dm9000_init_dm9000(), which expects the caller to hold that lock and accesses
> the chip registers directly. For DM9000B devices dm9000_init_dm9000() also
> calls dm9000_phy_write(), and that function takes db->lock again, so the TX
> timeout path deadlocks on the same CPU.
>
> dm9000_phy_write() already skips db->addr_lock when db->in_timeout is set,
> because in that case the caller holds db->lock and sleeping is not allowed
> either. Skip db->lock as well then, so that the nested call from
> dm9000_init_dm9000() works as intended.
>
> Fixes: 6741f40 ("DM9000B: driver initialization upgrade")
> Signed-off-by: Ginger Li <ginger.jzllee@gmail.com>
> ---
> drivers/net/ethernet/davicom/dm9000.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -325,10 +325,10 @@ dm9000_phy_write(struct net_device *dev,
> unsigned long reg_save;
>
> dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
> - if (!db->in_timeout)
> + if (!db->in_timeout) {
> mutex_lock(&db->addr_lock);
> -
> - spin_lock_irqsave(&db->lock, flags);
> + spin_lock_irqsave(&db->lock, flags);
> + }
This is ugly.
Is it possible to pull the locking out of dm9000_phy_write() to give a
version which tests the lock is taken using lockdep_assert_held(). Put
a wrapper around it which takes the lock for the normal case.
I would also take a look at dm9000_phy_read() and understand why its
locking is different.
Ideally you want to remove db->in_timeout, and make sure locked or
unlocked functions are called as needed. I assume you have the
hardware, and can trigger a timeout? So you can do a bigger refactor
like this?
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-23 18:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-23 8:40 [PATCH net] net: dm9000: Fix a recursive lockup in the TX timeout path Ginger Li
2026-09-23 18:47 ` Markus Elfring
2026-09-23 18:55 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®