From: Kalle Valo <kvalo@kernel.org>
To: Baochen Qiang <quic_bqiang@quicinc.com>
Cc: <ath12k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 01/10] wifi: ath12k: convert struct ath12k::wmi_mgmt_tx_work to struct wiphy_work
Date: Thu, 28 Nov 2024 14:08:53 +0200 [thread overview]
Message-ID: <87y113v9uy.fsf@kernel.org> (raw)
In-Reply-To: <83b2325e-4d98-49a1-ae32-a69d7962e4a3@quicinc.com> (Baochen Qiang's message of "Wed, 27 Nov 2024 10:34:00 +0800")
Baochen Qiang <quic_bqiang@quicinc.com> writes:
> On 11/27/2024 1:11 AM, Kalle Valo wrote:
>> From: Kalle Valo <quic_kvalo@quicinc.com>
>>
>> --- a/drivers/net/wireless/ath/ath12k/mac.c
>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
>> @@ -6726,6 +6726,8 @@ static void ath12k_mgmt_over_wmi_tx_drop(struct ath12k *ar, struct sk_buff *skb)
>> {
>> int num_mgmt;
>>
>> + lockdep_assert_wiphy(ath12k_ar_to_hw(ar)->wiphy);
>
> why would we need wiphy lock protect here? I don;t see anything in this function need it.
>
>> +
>> ieee80211_free_txskb(ath12k_ar_to_hw(ar), skb);
>>
>> num_mgmt = atomic_dec_if_positive(&ar->num_pending_mgmt_tx);
>> @@ -6787,6 +6789,8 @@ static int ath12k_mac_mgmt_tx_wmi(struct ath12k *ar, struct ath12k_link_vif *arv
>> int buf_id;
>> int ret;
>>
>> + lockdep_assert_wiphy(ath12k_ar_to_hw(ar)->wiphy);
>
> and here the same question as above. I know this function is only called from
> ath12k_mgmt_over_wmi_tx_work() which is under wiphy lock protection. But the function
> itself doesn't need to assert it if the function does not need its protection.
>
>> +
>> ATH12K_SKB_CB(skb)->ar = ar;
>> spin_lock_bh(&ar->txmgmt_idr_lock);
>> buf_id = idr_alloc(&ar->txmgmt_idr, skb, 0,
>> @@ -6841,7 +6845,7 @@ static void ath12k_mgmt_over_wmi_tx_purge(struct ath12k *ar)
>> ath12k_mgmt_over_wmi_tx_drop(ar, skb);
>> }
>>
>> -static void ath12k_mgmt_over_wmi_tx_work(struct work_struct *work)
>> +static void ath12k_mgmt_over_wmi_tx_work(struct wiphy *wiphy, struct wiphy_work *work)
>> {
>> struct ath12k *ar = container_of(work, struct ath12k, wmi_mgmt_tx_work);
>> struct ath12k_skb_cb *skb_cb;
>> @@ -6850,6 +6854,8 @@ static void ath12k_mgmt_over_wmi_tx_work(struct work_struct *work)
>> struct sk_buff *skb;
>> int ret;
>>
>> + lockdep_assert_wiphy(wiphy);
>
> we are definitely under wiphy lock protection since this is a wiphy_work item, hence no
> need to assert it explicitly. see also
>
> ieee80211_sta_monitor_work()
> ieee80211_beacon_connection_loss_work()
> ieee80211_csa_connection_drop_work()
> ieee80211_teardown_ttlm_work()
I have deliberately added all these lockdep_assert_wiphy() calls to
document which functions are called with wiphy_lock() held, otherwise
doing any locking analysis is much harder. My plan is that once MLO
support has landed to ath-next my plan is to document ath12k locking
design properly in the code. I think at that point we can also discuss
how we should use lockdep_assert_wiphy() in ath12k and should we drop
the extra calls.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-11-28 12:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 17:11 [PATCH 00/10] wifi: ath12k: MLO support part 4 Kalle Valo
2024-11-26 17:11 ` [PATCH 01/10] wifi: ath12k: convert struct ath12k::wmi_mgmt_tx_work to struct wiphy_work Kalle Valo
2024-11-27 2:34 ` Baochen Qiang
2024-11-28 12:08 ` Kalle Valo [this message]
2024-11-29 1:40 ` Baochen Qiang
2024-11-29 11:18 ` Kalle Valo
2024-11-26 17:11 ` [PATCH 02/10] wifi: ath12k: ath12k_mac_op_tx(): MLO support Kalle Valo
2024-11-27 2:49 ` Baochen Qiang
2024-11-28 12:32 ` Kalle Valo
2024-11-29 1:45 ` Baochen Qiang
2024-11-26 17:11 ` [PATCH 03/10] wifi: ath12k: ath12k_mac_op_flush(): " Kalle Valo
2024-11-26 17:11 ` [PATCH 04/10] wifi: ath12k: ath12k_mac_op_ampdu_action(): " Kalle Valo
2024-11-26 17:11 ` [PATCH 05/10] wifi: ath12k: ath12k_mac_station_add(): fix potential rx_stats leak Kalle Valo
2024-11-26 17:11 ` [PATCH 06/10] wifi: ath12k: do not return invalid link id for scan link Kalle Valo
2024-11-27 3:06 ` Baochen Qiang
2024-11-28 12:34 ` Kalle Valo
2024-11-29 1:46 ` Baochen Qiang
2024-11-28 0:24 ` Ping-Ke Shih
2024-11-26 17:11 ` [PATCH 07/10] wifi: ath12k: ath12k_bss_assoc(): MLO support Kalle Valo
2024-11-26 17:11 ` [PATCH 08/10] wifi: ath12k: defer vdev creation for MLO Kalle Valo
2024-11-26 17:11 ` [PATCH 09/10] wifi: ath12k: ath12k_mac_op_set_key(): fix uninitialized symbol 'ret' Kalle Valo
2024-11-26 17:11 ` [PATCH 10/10] wifi: ath12k: ath12k_mac_op_sta_rc_update(): use mac80211 provided link id Kalle Valo
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=87y113v9uy.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_bqiang@quicinc.com \
/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.