Re: [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll contextg

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-02 01:41:51 [+0200], Karl Mehltretter wrote:
> On Thu, Oct 01, 2026 at 09:57:55AM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-09-30 20:54:17 [+0200], Karl Mehltretter wrote:
> > > This fixes the direct SDIO transmit path used by fcmode=0. Modes 1 and 2
> > > take the FWS lock first and need a separate change.
> > 
> > Is this the only affected driver?
> 
> I also reproduced a sleeping-lock warning with 8139cp on PREEMPT_RT
> using QEMU's RTL8139C+ device. Enabling a dynamic netconsole target caused
> the printer thread to enter cp_start_xmit() with hard interrupts disabled:
> 
>   BUG: sleeping function called from invalid context
>   in_atomic(): 0, irqs_disabled(): 1, pid: 107, name: pr/netcon0
>   hardirqs last disabled at netpoll_send_skb+0x1c8/0x3d0
>   rt_spin_lock
>   cp_start_xmit+0x31/0x8b6 [8139cp]
>   netpoll_start_xmit+0x18e/0x260
>   netpoll_send_skb+0x37a/0x3d0
>   netconsole_write+0x56d/0x820
> 
> That was one reproduction on the netdev base a7bfaba4823e. I have not
> established how many drivers are affected.
> 
> Source inspection also identified 8139too and macb as candidates: their
> transmit paths take ordinary spinlock_t locks. I have not reproduced the
> warning with either driver.

I just replied to the netconsole thread where I did suggest to lift the
local_irq_save() part. This would obsolete this.

> The earlier netpoll/NBCON discussion concerns NAPI polling and
> scheduler-lock deadlocks, rather than this driver-lock warning:
> 
> https://lore.kernel.org/linux-rt-devel/20260618111554.2n0pP_O9@linutronix.de/

There was no fan club behind this change and PeterZ hated it so I
dropped it.
But this deadlock should not happen with nbcon or do I mix up things?

> > Do you have maybe a backtrace?
> > 
> 
> This is the original Pi 400 report on 7.3-rc3 with PREEMPT_RT. That kernel
> also had unrelated allocation-test patches applied. DEBUG_ATOMIC_SLEEP
> was disabled, so this report is the BH-disable warning:
…

I don't mind if you have something to optimise the driver. But as far as
the netconsole part goes, I would try to kill it at the upper level so
the driver is not affected.

> Thanks,
> Karl

Sebastian