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

[Bert Karwatzki]

Am Dienstag, dem 17.02.2026 um 17:52 +0100 schrieb Bert Karwatzki:
> Am Dienstag, dem 17.02.2026 um 12:24 +0100 schrieb Bert Karwatzki:
> > 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:
> 
> My argument above seems wrong: In the non-preempt case we cannot have another thread accessing the txq
> from the same CPU if the lock is taken (it is not preemptible) and for other threads
> accessing the txq from different CPUs the check (txq->xmit_lock_owner != cpu) would succeed
> and they would try the spinlock anyway, So this would not speak against killing the lock owner
> check. As for the recursion detection, perhaps dev_xmit_recursion() is enough?

I tried to research the original commit which introduced the xmit_lock_owner check, but
it is present since linux 2.3.6 (released 19990610) (when __dev_queue_xmit() was still called dev_queue_xmit()),
so I can't tell the original idea behind that check (perhaps recuesion detection ...), so I'm
not completely sure if it can be omitted (and just let dev_xmit_recursion() do the recursion checking).

Bert Karwatzki