Re: [PATCH v2] wifi: ath12k: fix false positive RCU warnings on PREEMPT_RT

Sebastian Andrzej Siewior
2026-04-22T14:23:28Z

On 2026-04-22 01:25:00 [+0800], Yu-Hsiang Tseng wrote:
> Two functions in ath12k assert that the caller holds an RCU read lock:
> ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
>
> WARN_ON(!rcu_read_lock_any_held());
>
> On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
> false positive splat whenever these functions are invoked from paths
> that do hold the RCU read lock (e.g. firmware stats processing or
> mac80211 interface iteration).

It depends what RCU section is expected/ tested for. SMP+preempt can use
preemptible RCU which does not disable preemption either. So this is not
PREEMPT_RT specific. It would be PREEMPT_RT specific if the RCU section
is implied by NAPI processing to so.

> Root cause:
>
> - On !PROVE_RCU, rcu_read_lock_any_held() is a static inline that
> returns !preemptible() as a proxy for "in an RCU read section".
>
> - On PREEMPT_RT, rcu_read_lock() does not disable preemption. A
> task can therefore be preemptible while legitimately holding an
> RCU read lock.

As elaborated above, this is not PREEMPT_RT specific but preemptible
TREE RCU.

> - Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
> and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
> read lock, so these warnings are incorrect.

If both this then use this then I guess something like
lockdep_assert_in_rcu_read_lock()

is what you look for.

> Typical splat seen on a WCN7850 station with periodic fw stats
> processing:
>
> WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
> ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
> Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
> Call Trace:
> ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
> ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
> ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
> ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
> ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
> ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
> ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]

If that is the call chain and there are no spinlocks involved then
PREEMPT+SMP+lockdep should trigger with this patch, too. The suggestion
above restricts this to lockdep only but your patch does so to.

Sebastian