wifi: mac80211: lockdep splat with 6.7-rc1

wifi: mac80211: lockdep splat with 6.7-rc1

[Johan Hovold]

Hi,

I get the lockdep splat below when booting 6.7-rc1 with ath11k (Lenovo
ThinkPad X13s).

It's the new assert added by commit 0e8185ce1dde ("wifi: mac80211: check
wiphy mutex in ops") which triggers in drv_get_txpower().

Naively adding locking around the call in ieee80211_get_tx_power()
(e.g. similar to 6b348f6e34ce ("wifi: mac80211: ethtool: always hold
wiphy mutex")) does not work as there are other paths that call this
function with the lock held, specifically via ieee80211_register_hw().

Johan


[    7.122642] ------------[ cut here ]------------
[    7.125125] WARNING: CPU: 1 PID: 453 at net/mac80211/driver-ops.h:1262 ieee80211_get_tx_power+0x19c/0x1c0 [mac80211]
[    7.126869] Modules linked in: cbc des_generic libdes algif_skcipher md5 algif_hash af_alg r8152(+) mii ip6_tables x
t_LOG nf_log_syslog ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack libcrc32c nf_defrag_ipv6 nf_defrag_ip
v4 snd_q6apm(+) iptable_filter qrtr_mhi panel_edp snd_soc_hdmi_codec venus_dec venus_enc videobuf2_dma_contig videobuf2
_memops apr rpmsg_ctrl rpmsg_char qrtr_smd fastrpc qcom_pm8008_regulator venus_core ath11k_pci qcom_battmgr pmic_glink_
altmode ath11k snd_soc_wcd938x v4l2_mem2mem hci_uart mac80211 leds_qcom_lpg snd_soc_wcd_classh libarc4 btqca videobuf2_
v4l2 led_class_multicolor snd_soc_wcd938x_sdw videodev regmap_sdw bluetooth snd_soc_lpass_rx_macro videobuf2_common snd
_soc_lpass_va_macro snd_soc_lpass_tx_macro snd_soc_lpass_wsa_macro snd_soc_sc8280xp msm cfg80211 qcom_spmi_adc_tm5 snd_
soc_qcom_common soundwire_qcom snd_soc_wcd_mbhc ecdh_generic snd_soc_qcom_sdw snd_soc_lpass_macro_common qcom_spmi_adc5
 qcom_spmi_temp_alarm gpu_sched ecc phy_qcom_qmp_combo mc qcom_pon
[    7.127338]  drm_display_helper gpio_sbu_mux drm_dp_aux_bus snd_soc_core reboot_mode qcom_pm8008 mhi rtc_pm8xxx drm_
kms_helper industrialio rfkill mfd_core dispcc_sc8280xp nvmem_qcom_spmi_sdam qcom_vadc_common typec qcom_stats snd_comp
ress qcom_q6v5_pas regmap_i2c llcc_qcom phy_qcom_edp icc_bwmon pinctrl_sc8280xp_lpass_lpi snd_pcm videocc_sm8350 phy_qc
om_qmp_usb qcom_pil_info snd_timer phy_qcom_snps_femto_v2 gpucc_sc8280xp qcom_common qrtr pinctrl_lpass_lpi lpasscc_sc8
280xp snd qcom_glink_smem qcom_q6v5 soundcore qcom_rng pmic_glink qcom_sysmon soundwire_bus pdr_interface mdt_loader rn
g_core icc_osm_l3 qmi_helpers qcom_wdt socinfo pwm_bl dm_mod ip_tables x_tables ipv6 pcie_qcom crc8 phy_qcom_qmp_pcie n
vme nvme_core hid_multitouch i2c_qcom_geni i2c_hid_of i2c_hid drm i2c_core
[    7.127494] CPU: 1 PID: 453 Comm: iwd Not tainted 6.7.0-rc1 #4
[    7.127501] Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET53W (1.25 ) 10/12/2022
[    7.127506] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    7.127513] pc : ieee80211_get_tx_power+0x19c/0x1c0 [mac80211]
[    7.127603] lr : ieee80211_get_tx_power+0x198/0x1c0 [mac80211]
[    7.127682] sp : ffff8000821e36c0
[    7.127686] x29: ffff8000821e36c0 x28: ffff08bb443dcd00 x27: 0000000000000000
[    7.127696] x26: ffffa0d9a6fb6638 x25: ffff08bb58ad0700 x24: 0000000000000000
[    7.127706] x23: ffffa0d9b3cc0b80 x22: ffff8000821e3784 x21: ffff08bb58ad0000
[    7.127715] x20: ffff08bb57a4cb10 x19: ffff08bb58ad0e40 x18: 0000000000000002
[    7.127724] x17: 0000000000000000 x16: ffffa0d9b3629db8 x15: 0000000000000002
[    7.127732] x14: 0000000000000000 x13: 00000000fffffffc x12: 0000000000000000
[    7.127741] x11: 0000000000000010 x10: ffffa0d9b45d7258 x9 : 0000000000000000
[    7.127750] x8 : ffff08bb4d663200 x7 : 0000000000000000 x6 : 0000000000000078
[    7.127759] x5 : ffffa0d9b3ec0000 x4 : ffff08bb4d663200 x3 : 0000000000000000
[    7.127767] x2 : ffff67ece049d000 x1 : 0000000000000000 x0 : 0000000000000000
[    7.127777] Call trace:
[    7.127780]  ieee80211_get_tx_power+0x19c/0x1c0 [mac80211]
[    7.127859]  nl80211_send_iface+0x208/0x6a4 [cfg80211]
[    7.127946]  nl80211_dump_interface+0x120/0x254 [cfg80211]
[    7.128027]  genl_dumpit+0x48/0xcc
[    7.128045]  netlink_dump+0x120/0x3c4
[    7.128051]  __netlink_dump_start+0x198/0x2c8
[    7.128057]  genl_family_rcv_msg_dumpit+0x88/0x114
[    7.128063]  genl_rcv_msg+0x118/0x28c
[    7.128069]  netlink_rcv_skb+0x58/0x13c
[    7.128075]  genl_rcv+0x38/0x50
[    7.128080]  netlink_unicast+0x1d4/0x2c0
[    7.128086]  netlink_sendmsg+0x1ac/0x414
[    7.128092]  __sys_sendto+0x130/0x184
[    7.128098]  __arm64_sys_sendto+0x28/0x38
[    7.128102]  invoke_syscall+0x48/0x114
[    7.128113]  el0_svc_common.constprop.0+0xc0/0xe0
[    7.128120]  do_el0_svc+0x1c/0x28
[    7.128127]  el0_svc+0x48/0xd8
[    7.128136]  el0t_64_sync_handler+0xc0/0xc4
[    7.128143]  el0t_64_sync+0x190/0x194
[    7.128148] irq event stamp: 44690
[    7.128152] hardirqs last  enabled at (44689): [<ffffa0d9b2ef6adc>] __kmalloc_large_node+0x120/0x194
[    7.128162] hardirqs last disabled at (44690): [<ffffa0d9b3627f78>] el1_dbg+0x24/0x8c
[    7.128170] softirqs last  enabled at (39582): [<ffffa0d9a737b0d4>] ieee80211_get_txq_stats+0xb0/0x1ac [mac80211]
[    7.128252] softirqs last disabled at (39580): [<ffffa0d9a737b060>] ieee80211_get_txq_stats+0x3c/0x1ac [mac80211]
[    7.128331] ---[ end trace 0000000000000000 ]---

Re: wifi: mac80211: lockdep splat with 6.7-rc1

[Johannes Berg]

On Tue, 2023-11-14 at 16:50 +0100, Johan Hovold wrote:
> Hi,
> 
> I get the lockdep splat below when booting 6.7-rc1 with ath11k (Lenovo
> ThinkPad X13s).
> 
> It's the new assert added by commit 0e8185ce1dde ("wifi: mac80211: check
> wiphy mutex in ops") which triggers in drv_get_txpower().
> 
> Naively adding locking around the call in ieee80211_get_tx_power()
> (e.g. similar to 6b348f6e34ce ("wifi: mac80211: ethtool: always hold
> wiphy mutex")) does not work as there are other paths that call this
> function with the lock held, specifically via ieee80211_register_hw().

The latter we can just take the lock I guess?

> [    7.127780]  ieee80211_get_tx_power+0x19c/0x1c0 [mac80211]
> [    7.127859]  nl80211_send_iface+0x208/0x6a4 [cfg80211]
> [    7.127946]  nl80211_dump_interface+0x120/0x254 [cfg80211]
> 

And here maybe we should just take the mutex at the nl80211 level.
That's the nice thing now, it's shared between the layers :)

I can't do it right now, but I'll take a look tomorrow.

johannes

Re: wifi: mac80211: lockdep splat with 6.7-rc1

[Johan Hovold]

On Tue, Nov 14, 2023 at 06:02:33PM +0100, Johannes Berg wrote:
> On Tue, 2023-11-14 at 16:50 +0100, Johan Hovold wrote:

> > Naively adding locking around the call in ieee80211_get_tx_power()
> > (e.g. similar to 6b348f6e34ce ("wifi: mac80211: ethtool: always hold
> > wiphy mutex")) does not work as there are other paths that call this
> > function with the lock held, specifically via ieee80211_register_hw().
> 
> The latter we can just take the lock I guess?

ieee80211_register_hw() is specifically already taking the lock. 
 
> > [    7.127780]  ieee80211_get_tx_power+0x19c/0x1c0 [mac80211]
> > [    7.127859]  nl80211_send_iface+0x208/0x6a4 [cfg80211]
> > [    7.127946]  nl80211_dump_interface+0x120/0x254 [cfg80211]
> 
> And here maybe we should just take the mutex at the nl80211 level.

Yeah, it looks like you can possibly add it to nl80211_dump_interface().

nl80211_send_iface() is already called in paths like:

    ieee80211_get_tx_power+0x28/0x1c0 [mac80211]
    nl80211_send_iface+0x208/0x6a4 [cfg80211]
    nl80211_notify_iface+0x58/0xcc [cfg80211]
    cfg80211_register_wdev+0xa0/0x12c [cfg80211]
    cfg80211_register_netdevice+0x7c/0x108 [cfg80211]
    ieee80211_if_add+0x4b0/0x5cc [mac80211]
    ieee80211_register_hw+0xbec/0xc2c [mac80211]

> That's the nice thing now, it's shared between the layers :)
> 
> I can't do it right now, but I'll take a look tomorrow.

Sounds good, thanks.

Johan