[PATCH] wifi: ath12k: fix false positive RCU warning on PREEMPT_RT

[PATCH] wifi: ath12k: fix false positive RCU warning on PREEMPT_RT

[Yu-Hsiang Tseng]

ath12k_mac_get_arvif() asserts that the caller holds an RCU read lock:

    WARN_ON(!rcu_read_lock_any_held());

On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
false positive splat whenever firmware stats events are processed,
even though the caller does hold the RCU read lock.

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.

  - ath12k_wmi_tlv_rssi_chain_parse() holds the RCU read lock via
    guard(rcu)() before calling ath12k_mac_get_arvif(), so the
    warning is incorrect.

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]

Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
debug_lockdep_rcu_enabled() and therefore compiles out entirely
when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
full lockdep-based check.

Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
---
 drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index fbdfe6424fd7..a772a5b6adc9 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -788,7 +788,8 @@ struct ath12k_link_vif *ath12k_mac_get_arvif(struct ath12k *ar, u32 vdev_id)
 
 	/* To use the arvif returned, caller must have held rcu read lock.
 	 */
-	WARN_ON(!rcu_read_lock_any_held());
+	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
+			 "RCU read lock not held");
 	arvif_iter.vdev_id = vdev_id;
 	arvif_iter.ar = ar;
 
-- 
2.53.0

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

[Baochen Qiang]

On 4/21/2026 12:10 AM, Yu-Hsiang Tseng wrote:
> ath12k_mac_get_arvif() asserts that the caller holds an RCU read lock:
> 
>     WARN_ON(!rcu_read_lock_any_held());
> 
> On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
> false positive splat whenever firmware stats events are processed,
> even though the caller does hold the RCU read lock.
> 
> 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.
> 
>   - ath12k_wmi_tlv_rssi_chain_parse() holds the RCU read lock via
>     guard(rcu)() before calling ath12k_mac_get_arvif(), so the
>     warning is incorrect.
> 
> 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]
> 
> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> full lockdep-based check.
> 
> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
> ---
>  drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index fbdfe6424fd7..a772a5b6adc9 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -788,7 +788,8 @@ struct ath12k_link_vif *ath12k_mac_get_arvif(struct ath12k *ar, u32 vdev_id)
>  
>  	/* To use the arvif returned, caller must have held rcu read lock.
>  	 */
> -	WARN_ON(!rcu_read_lock_any_held());
> +	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> +			 "RCU read lock not held");

should the instance in ath12k_p2p_noa_update_vdev_iter() also need to be replaced?

>  	arvif_iter.vdev_id = vdev_id;
>  	arvif_iter.ar = ar;
>  

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

[Yu-Hsiang Tseng]

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).

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.

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

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]

Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
debug_lockdep_rcu_enabled() and therefore compiles out entirely
when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
full lockdep-based check.

Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
---
Changes in v2:
  - Also fix the same WARN_ON() in ath12k_p2p_noa_update_vdev_iter()
    (suggested by Baochen Qiang)
  - Update commit message to cover both call sites

Link to v1: https://lore.kernel.org/ath12k/20260420161049.695518-1-asas1asas200@gmail.com/

 drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
 drivers/net/wireless/ath/ath12k/p2p.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index fbdfe6424fd7..a772a5b6adc9 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -788,7 +788,8 @@ struct ath12k_link_vif *ath12k_mac_get_arvif(struct ath12k *ar, u32 vdev_id)
 
 	/* To use the arvif returned, caller must have held rcu read lock.
 	 */
-	WARN_ON(!rcu_read_lock_any_held());
+	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
+			 "RCU read lock not held");
 	arvif_iter.vdev_id = vdev_id;
 	arvif_iter.ar = ar;
 
diff --git a/drivers/net/wireless/ath/ath12k/p2p.c b/drivers/net/wireless/ath/ath12k/p2p.c
index 59589748f1a8..caa92612372b 100644
--- a/drivers/net/wireless/ath/ath12k/p2p.c
+++ b/drivers/net/wireless/ath/ath12k/p2p.c
@@ -123,7 +123,8 @@ static void ath12k_p2p_noa_update_vdev_iter(void *data, u8 *mac,
 	struct ath12k_p2p_noa_arg *arg = data;
 	struct ath12k_link_vif *arvif;
 
-	WARN_ON(!rcu_read_lock_any_held());
+	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
+			 "RCU read lock not held");
 	arvif = &ahvif->deflink;
 	if (!arvif->is_created || arvif->ar != arg->ar || arvif->vdev_id != arg->vdev_id)
 		return;
-- 
2.53.0

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

[Rameshkumar Sundaram]

On 4/21/2026 10:55 PM, 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).
> 
> 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.
> 
>    - 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.
> 
> 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]
> 
> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> full lockdep-based check.
> 
> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>

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

[Yu-Hsiang Tseng]

On Tue, Apr 21, 2026 at 10:24:36AM +0800, Baochen Qiang wrote:
> should the instance in ath12k_p2p_noa_update_vdev_iter() also need to
> be replaced?

Good catch, thanks. Sent v2 that also converts the WARN_ON() in
ath12k_p2p_noa_update_vdev_iter() to RCU_LOCKDEP_WARN().

v2: https://lore.kernel.org/ath12k/20260421172500.1050754-1-asas1asas200@gmail.com/

Thanks,
Yu-Hsiang

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

[Jeff Johnson]

On 4/21/2026 10:25 AM, 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).
> 
> 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.
> 
>   - 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.
> 
> 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]
> 
> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> full lockdep-based check.
> 
> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Note that Tested-on: is not a official upstream tag, it is an ath-specific
tag. Since it is not an official tag, it should be specified separately from
the official tags:

<commit text>
<blank line>
Tested-on: ...
<blank line>
<official upstream tags>
Signed-off-by: ...

Unless there are are other review comments there is no need to send a v3 to
address this -- I can make this change when I pick up the patch.

> Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
> ---
> Changes in v2:
>   - Also fix the same WARN_ON() in ath12k_p2p_noa_update_vdev_iter()
>     (suggested by Baochen Qiang)
>   - Update commit message to cover both call sites

Note that you made v2 In-reply-to the v1 patch. In kernel.org code review that
is NOT preferred. In kernel.org it is preferred that each version of a patch
be a separate thread.

> 
> Link to v1: https://lore.kernel.org/ath12k/20260420161049.695518-1-asas1asas200@gmail.com/
> 
>  drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
>  drivers/net/wireless/ath/ath12k/p2p.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index fbdfe6424fd7..a772a5b6adc9 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -788,7 +788,8 @@ struct ath12k_link_vif *ath12k_mac_get_arvif(struct ath12k *ar, u32 vdev_id)
>  
>  	/* To use the arvif returned, caller must have held rcu read lock.
>  	 */
> -	WARN_ON(!rcu_read_lock_any_held());
> +	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> +			 "RCU read lock not held");
>  	arvif_iter.vdev_id = vdev_id;
>  	arvif_iter.ar = ar;
>  
> diff --git a/drivers/net/wireless/ath/ath12k/p2p.c b/drivers/net/wireless/ath/ath12k/p2p.c
> index 59589748f1a8..caa92612372b 100644
> --- a/drivers/net/wireless/ath/ath12k/p2p.c
> +++ b/drivers/net/wireless/ath/ath12k/p2p.c
> @@ -123,7 +123,8 @@ static void ath12k_p2p_noa_update_vdev_iter(void *data, u8 *mac,
>  	struct ath12k_p2p_noa_arg *arg = data;
>  	struct ath12k_link_vif *arvif;
>  
> -	WARN_ON(!rcu_read_lock_any_held());
> +	RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(),
> +			 "RCU read lock not held");
>  	arvif = &ahvif->deflink;
>  	if (!arvif->is_created || arvif->ar != arg->ar || arvif->vdev_id != arg->vdev_id)
>  		return;

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

[Baochen Qiang]

On 4/22/2026 1:25 AM, 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).
> 
> 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.
> 
>   - 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.
> 
> 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]
> 
> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> full lockdep-based check.
> 
> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>

Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>

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

[Jeff Johnson]

On 4/21/2026 2:27 PM, Jeff Johnson wrote:
> On 4/21/2026 10:25 AM, 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).
>>
>> 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.
>>
>>   - 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.
>>
>> 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]
>>
>> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
>> debug_lockdep_rcu_enabled() and therefore compiles out entirely
>> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
>> full lockdep-based check.
>>
>> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> 
> Note that Tested-on: is not a official upstream tag, it is an ath-specific
> tag. Since it is not an official tag, it should be specified separately from
> the official tags:
> 
> <commit text>
> <blank line>
> Tested-on: ...
> <blank line>
> <official upstream tags>
> Signed-off-by: ...
> 
> Unless there are are other review comments there is no need to send a v3 to
> address this -- I can make this change when I pick up the patch.
Amended patch in my pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd

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

[Sebastian Andrzej Siewior]

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

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

[Yu-Hsiang Tseng]

On Wed, Apr 22, 2026 at 04:23:25PM +0200, Sebastian Andrzej Siewior wrote:
> As elaborated above, this is not PREEMPT_RT specific but preemptible
> TREE RCU.

You're right. Sent v3 that clarifies the scope (preemptible RCU in
general, not only PREEMPT_RT).

> If both this then use this then I guess something like
>     lockdep_assert_in_rcu_read_lock()
> is what you look for.

Adopted in v3 - thanks for the pointer, it reads much cleaner than
RCU_LOCKDEP_WARN().

v3: https://lore.kernel.org/ath12k/20260422180814.1938317-1-asas1asas200@gmail.com/

Thanks,
Yu-Hsiang

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

[曾昱翔]

On Wed, Apr 22, 2026 at 06:33:45 -0700, Jeff Johnson wrote:
> Amended patch in my pending branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd

Thanks for picking it up and fixing the Tested-on placement.

Sebastian pointed out on v2 that the fix should use
lockdep_assert_in_rcu_read_lock() rather than RCU_LOCKDEP_WARN(),
since the former is gated on CONFIG_PROVE_RCU (same effect) but
expresses the intent more precisely. He also noted that the bug
is not PREEMPT_RT specific but applies to preemptible RCU in
general.

I've sent v3 addressing both points:
https://lore.kernel.org/ath12k/20260422180814.1938317-1-asas1asas200@gmail.com/

Let me know if you'd like me to do anything further.

Thanks,
Yu-Hsiang


Jeff Johnson <jeff.johnson@oss.qualcomm.com> 於 2026年4月22日週三 下午9:33寫道：
>
> On 4/21/2026 2:27 PM, Jeff Johnson wrote:
> > On 4/21/2026 10:25 AM, 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).
> >>
> >> 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.
> >>
> >>   - 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.
> >>
> >> 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]
> >>
> >> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> >> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> >> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> >> full lockdep-based check.
> >>
> >> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> >> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> >
> > Note that Tested-on: is not a official upstream tag, it is an ath-specific
> > tag. Since it is not an official tag, it should be specified separately from
> > the official tags:
> >
> > <commit text>
> > <blank line>
> > Tested-on: ...
> > <blank line>
> > <official upstream tags>
> > Signed-off-by: ...
> >
> > Unless there are are other review comments there is no need to send a v3 to
> > address this -- I can make this change when I pick up the patch.
> Amended patch in my pending branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd