Re: [net,PATCH v3 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler

From: Marek Vasut

Date: Thu Apr 16 2026 - 05:31:24 EST

On 4/16/26 8:21 AM, Sebastian Andrzej Siewior wrote:
On 2026-04-16 01:14:35 [+0200], Marek Vasut wrote:
spin_unlock_bh(&ks->statelock)? After that unlock, the softirq must be
processed and __netdev_alloc_skb() _could_ observe pending softirqs but
not from ks8851.
Because __netdev_alloc_skb() also enables/disables BH , see the "else"

Yes. But there is no softirq raised in that part. That softirq is raised
by netif_wake_queue() within a bh disabled section. Therefore upon the
unlock the softirq must be invoked.
After that, rhe allocation later on may invoke softirqs which were
raised but I don't see how ks8851 can be part of it.
Before commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI
chip variant") there was no _bh around it meaning the softirq was raised
but not invoked immediately. This happened on the bh unlock during
memory allocation. Therefore I am saying this backtrace is from an older
kernel.

I actually did update the backtrace in V3 with the one from next 20260413 that contained b44596ffe1b4 ("ARM: Allow to enable RT") from stable-rt/v6.12-rt-rebase branch [1] .

I think I misunderstood the usage of "softirq is raised" vs. "softirq is invoked" above . Is it possible that there was an already raised softirq before the threaded IRQ handler was invoked, and __netdev_alloc_skb() is what invoked that softirq ?

If there is a flaw in my the theory please explain _how_ you managed
that get that backtrace. I am sure it must have from an older kernel and
_now_ this lockup also happens on !RT kernels (except for the SPI
platform).
I used [1] , with PREEMPT_RT enabled , on stm32mp157c SoC . I ran iperf3 -s on the stm32 side, iperf3 -c 192.168.1.2 -t 0 --bidir on the hostpc side. The backtrace happened shortly after.