From: Bert Karwatzki <spasswolf@web.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
spasswolf@web.de, Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org
Subject: Re: "Dead loop on virtual device" error without softirq-BKL on PREEMPT_RT
Date: Tue, 17 Feb 2026 12:24:12 +0100 [thread overview]
Message-ID: <fd609cfe186ee48e0e9a08e35764175a2516dd14.camel@web.de> (raw)
In-Reply-To: <4fba57892e5bd6a1afc4a36a80b40e3ecc28cac5.camel@web.de>
Am Dienstag, dem 17.02.2026 um 11:42 +0100 schrieb Bert Karwatzki:
>
> I just wondered if we can completely skip the
>
> if (READ_ONCE(txq->xmit_lock_owner) != cpu) {
> [...]
> } else
> {
> /* "Recursion" alert */
> }
>
> check, as the synchronization will we provided by HARD_TX_{LOCK,UNLOCK}.
>
I thought about that again, and it seems like a bad idea as (in the non-preempt) case
other threads trying to access the queue would wait for the spinlock to be freed, perhaps
one can just change the code like this:
commit 05026868843a4eea51d45811d87706f36896e828
Author: Bert Karwatzki <spasswolf@web.de>
Date: Tue Feb 17 12:08:35 2026 +0100
net: core: dev: don't warn about recursion when on same CPU
This prints a message if we're on the same CPU and the lock is
already taken, in a production use we would of course skip this
message.
Signed-off-by: Bert Karwatzki <spasswolf@web.de>
diff --git a/net/core/dev.c b/net/core/dev.c
index 5b536860138d..cac5588640b3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4784,15 +4784,18 @@ int __dev_queue_xmit(struct sk_buff *skb, struct net_device *sb_dev)
net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
dev->name);
} else {
- /* Recursion is detected! It is possible,
- * unfortunately
- */
-recursion_alert:
- net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\n",
- dev->name);
+ net_crit_ratelimited("Lock taken already on %s!\n", dev->name);
+ goto lock_taken;
}
}
+ /* Recursion is detected! It is possible,
+ * unfortunately
+ */
+recursion_alert:
+ net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\n",
+ dev->name);
+lock_taken:
rc = -ENETDOWN;
rcu_read_unlock_bh();
With this I get these messages (be skipped in production code)
instead of the "Dead loop on virtual device":
[ 51.994435] [ T1525] Lock taken already on wlp4s0!
[ 51.994546] [ T1525] Lock taken already on wlp4s0!
[ 51.994650] [ T1525] Lock taken already on wlp4s0!
[ 51.994746] [ T1525] Lock taken already on wlp4s0!
[ 51.994845] [ T1525] Lock taken already on wlp4s0!
[ 51.994948] [ T1525] Lock taken already on wlp4s0!
[ 51.995037] [ T1525] Lock taken already on wlp4s0!
[ 51.995128] [ T1525] Lock taken already on wlp4s0!
[ 51.995220] [ T1525] Lock taken already on wlp4s0!
Bert Karwatzki
next prev parent reply other threads:[~2026-02-17 11:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 13:43 "Dead loop on virtual device" error without softirq-BKL on PREEMPT_RT Bert Karwatzki
2026-02-16 15:32 ` Bert Karwatzki
2026-02-16 15:37 ` Sebastian Andrzej Siewior
2026-02-16 23:48 ` Bert Karwatzki
2026-02-17 7:19 ` Sebastian Andrzej Siewior
2026-02-17 8:56 ` Bert Karwatzki
2026-02-17 9:57 ` Sebastian Andrzej Siewior
2026-02-17 10:42 ` Bert Karwatzki
2026-02-17 11:24 ` Bert Karwatzki [this message]
2026-02-17 16:52 ` Bert Karwatzki
2026-02-17 19:10 ` Bert Karwatzki
2026-02-18 7:30 ` Sebastian Andrzej Siewior
2026-02-18 12:50 ` Bert Karwatzki
2026-02-26 17:29 ` Sebastian Andrzej Siewior
2026-03-18 10:30 ` Daniel Vacek
2026-03-18 11:18 ` Sebastian Andrzej Siewior
2026-03-18 14:43 ` Daniel Vacek
2026-03-18 14:51 ` Sebastian Andrzej Siewior
2026-03-18 14:58 ` Daniel Vacek
2026-04-01 16:55 ` Daniel Vacek
2026-04-02 7:03 ` Sebastian Andrzej Siewior
2026-04-02 7:50 ` Daniel Vacek
2026-04-02 8:31 ` Sebastian Andrzej Siewior
2026-04-02 9:21 ` Daniel Vacek
2026-04-02 13:46 ` Sebastian Andrzej Siewior
2026-04-02 13:58 ` Daniel Vacek
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=fd609cfe186ee48e0e9a08e35764175a2516dd14.camel@web.de \
--to=spasswolf@web.de \
--cc=bigeasy@linutronix.de \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.