Thread (18 messages) 18 messages, 3 authors, 2026-04-02

Re: "Dead loop on virtual device" error without softirq-BKL on PREEMPT_RT

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2026-03-18 14:51:03
Also in: linux-rt-devel, lkml

On 2026-03-18 15:43:52 [+0100], Daniel Vacek wrote:
On Wed, 18 Mar 2026 at 12:18, Sebastian Andrzej Siewior
[off-list ref] wrote:
quoted
On 2026-03-18 11:30:09 [+0100], Daniel Vacek wrote:
quoted
quoted
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4821,7 +4821,7 @@ int __dev_queue_xmit(struct sk_buff *skb, struct net_device *sb_dev)
            /* Other cpus might concurrently change txq->xmit_lock_owner
             * to -1 or to their cpu id, but not to our id.
             */
-           if (READ_ONCE(txq->xmit_lock_owner) != cpu) {
+           if (rt_mutex_owner(&txq->_xmit_lock.lock) != current) {
Ain't this changing the behavior for !RT case? Previously, if it was the same thread
which has already locked the queue (and hence the same CPU) evaluating this condition,
the condition was skipped, which is no longer the case with this change.
The above was me thinking and does not even compile for !RT. Commit
b824c3e16c190 ("net: Provide a PREEMPT_RT specific check for
netdev_queue::_xmit_lock") is what was merged in the end.
Hmm, that means txq->xmit_lock_owner is not used at all for PREEMT_RT.
It's pointless to even store it. Shall we care?
For PREEMPT_RT the xmit_lock_owner member is only stored and not used
otherwise. It could be removed as in ifdef-ed away but I do not care
enough to sprinkle it and the gain is little (proof me wrong). So I am
happy as-is.

As for the check itself as we have now, we detect the deadlock before it
happens and this is nice to have. The alternative (in case of a
deadlock) would be the deadlock detection in rtmutex code which would
freeze the thread.
--nX
Sebastian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help