All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl Mehltretter <kmehltretter@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	 g@mbp-von-karl.localdomain
Cc: linux-wireless@vger.kernel.org,
	 Arend van Spriel <arend.vanspriel@broadcom.com>,
	Clark Williams <clrkwllms@kernel.org>,
	 Steven Rostedt <rostedt@goodmis.org>,
	"David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	brcm80211@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com,
	 linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	stable@vger.kernel.org
Subject: Re: [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll contextg
Date: Fri, 2 Oct 2026 01:41:51 +0200	[thread overview]
Message-ID: <ar7vLt5kQ2HJoJY9@gmail.com> (raw)
In-Reply-To: <20261001075755.3MilPS2C@linutronix.de>

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.

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/

> 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:

  DEBUG_LOCKS_WARN_ON(this_cpu_read(softirq_ctrl.cnt))
  WARNING: kernel/softirq.c:199 at __local_bh_disable_ip+0xd8/0x200
  CPU#0: pr/netcon0/769
  Call trace:
   __local_bh_disable_ip+0xd8/0x200
   brcmf_sdio_bus_txdata+0x90/0x2b0 [brcmfmac]
   brcmf_proto_bcdc_txdata+0x90/0xb0 [brcmfmac]
   brcmf_proto_bcdc_tx_queue_data+0x60/0xa0 [brcmfmac]
   brcmf_netdev_start_xmit+0x164/0x390 [brcmfmac]
   netpoll_start_xmit+0x160/0x218
   netpoll_send_skb+0x208/0x2b0
   netpoll_send_udp+0x298/0x478
   netconsole_write+0x440/0x7a0
   netconsole_write_basic+0x20/0x40
   nbcon_emit_next_record+0x208/0x2a8
   nbcon_emit_one+0xc8/0x110
   nbcon_kthread_func+0x184/0x210

Thanks,
Karl

  reply	other threads:[~2026-10-01 23:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 18:54 [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll context Karl Mehltretter
2026-10-01  7:57 ` Sebastian Andrzej Siewior
2026-10-01 23:41   ` Karl Mehltretter [this message]
2026-10-09 16:00     ` [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll contextg Sebastian Andrzej Siewior
2026-10-11 19:42       ` Karl Mehltretter
2026-10-04 12:29 ` [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll context Arend van Spriel
2026-10-06  4:18   ` Karl Mehltretter
2026-10-06  8:27     ` Arend van Spriel
2026-10-09  7:30       ` Karl Mehltretter
2026-10-09 11:46         ` Arend van Spriel

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=ar7vLt5kQ2HJoJY9@gmail.com \
    --to=kmehltretter@gmail.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=bigeasy@linutronix.de \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211@lists.linux.dev \
    --cc=clrkwllms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=g@mbp-von-karl.localdomain \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    /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.