From: Kalle Valo <kvalo@kernel.org>
To: Aditya Kumar Singh <quic_adisi@quicinc.com>
Cc: Jeff Johnson <quic_jjohnson@quicinc.com>,
<ath12k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 3/8] wifi: ath12k: Refactor sta state machine
Date: Wed, 30 Oct 2024 20:28:21 +0200 [thread overview]
Message-ID: <87frodfnsq.fsf@kernel.org> (raw)
In-Reply-To: <cd19db4a-953d-4230-85b1-695140bb185c@quicinc.com> (Aditya Kumar Singh's message of "Wed, 30 Oct 2024 09:35:37 +0530")
Aditya Kumar Singh <quic_adisi@quicinc.com> writes:
> On 10/29/24 21:08, Kalle Valo wrote:
>> + aditya
>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>>
>>>> +static int ath12k_mac_station_unauthorize(struct ath12k *ar,
>>>> + struct ath12k_link_vif *arvif,
>>>> + struct ath12k_link_sta *arsta)
>>>> +{
>>>> + struct ath12k_peer *peer;
>>>> + int ret;
>>>> +
>>>> + lockdep_assert_wiphy(ath12k_ar_to_hw(ar)->wiphy);
>>>> +
>>>> + spin_lock_bh(&ar->ab->base_lock);
>>>> +
>>>> + peer = ath12k_peer_find(ar->ab, arvif->vdev_id, arsta->addr);
>>>> + if (peer)
>>>> + peer->is_authorized = false;
>>>> +
>>>> + spin_unlock_bh(&ar->ab->base_lock);
>>>> +
>>>> + /* Driver should clear the peer keys during mac80211's ref ptr
>>>> + * gets cleared in __sta_info_destroy_part2 (trans from
>>>> + * IEEE80211_STA_AUTHORIZED to IEEE80211_STA_ASSOC)
>>>
>>> I'm unable to understand this comment
>> Indeed, that's weird. Aditya, do you have any idea what the comment
>> is
>> trying to say?
>>
>
> At present, ath12k clear the keys in ath12k_station_disassoc() which
> gets executed in state change from IEEE80211_STA_ASSOC to
> IEEE80211_STA_AUTH.
>
> However, in mac80211, once the station moves from
> IEEE80211_STA_AUTHORIZED to IEEE80211_STA_ASSOC itself, the keys are
> deleted. Please see - __sta_info_destroy_part2() ->
> ieee80211_free_sta_keys().
>
> Now, ath12k peer object (struct ath12k_peer) holds the key reference
> from mac80211 (see ath12k_peer::keys[]). Hence, once mac80211 deletes
> the key, driver should not keep a reference to it or else it could
> lead to issues.
>
> Therefore, it is important that the driver should clear the peer keys
> during transition from IEEE80211_STA_AUTHORIZED to IEEE80211_STA_ASSOC
> it self since we know that once we return from here, mac80211 is going
> to remove the keys.
>
> ath12k_mac_station_unauthorize() gets called when station moves from
> state IEEE80211_STA_AUTHORIZED to IEEE80211_STA_ASSOC hence call to
> ath12k_clear_peer_keys() is moved from ath12k_station_disassoc() to
> ath12k_mac_station_unauthorize().
>
> Is this clear now?
Super clear :) Thanks!
> May be the comment in the code could be re-written as below?
>
> /* Driver must clear the keys during the state change from
> * IEEE80211_STA_AUTHORIZED to IEEE80211_STA_ASSOC, since after
> * returning from here, mac80211 is going to delete the keys
> * in __sta_info_destroy_part2(). This will ensure that the driver does
> * not retain stale key references after mac80211 deletes the keys.
> */
Looks good to me, I'll add that if it's ok for Jeff as well.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-10-30 18:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 13:29 [PATCH 0/8] wifi: ath12k: MLO support part 2 Kalle Valo
2024-10-23 13:29 ` [PATCH 1/8] wifi: ath12k: ath12k_mac_vdev_create(): use goto for error handling Kalle Valo
2024-10-23 15:01 ` Jeff Johnson
2024-10-24 17:21 ` Kalle Valo
2024-10-23 13:29 ` [PATCH 2/8] wifi: ath12k: MLO vdev bringup changes Kalle Valo
2024-10-23 15:19 ` Jeff Johnson
2024-10-24 18:10 ` Kalle Valo
2024-10-23 13:29 ` [PATCH 3/8] wifi: ath12k: Refactor sta state machine Kalle Valo
2024-10-23 15:38 ` Jeff Johnson
2024-10-29 15:29 ` Kalle Valo
2024-10-29 15:35 ` Jeff Johnson
2024-10-29 15:38 ` Kalle Valo
2024-10-30 4:05 ` Aditya Kumar Singh
2024-10-30 18:28 ` Kalle Valo [this message]
2024-10-30 18:39 ` Jeff Johnson
2024-10-24 2:58 ` Baochen Qiang
2024-10-26 9:08 ` Kalle Valo
2024-10-23 13:30 ` [PATCH 4/8] wifi: ath12k: introduce ath12k_hw_warn() Kalle Valo
2024-10-23 15:38 ` Jeff Johnson
2024-10-29 15:41 ` Kalle Valo
2024-10-23 13:30 ` [PATCH 5/8] wifi: ath12k: Add helpers for multi link peer creation and deletion Kalle Valo
2024-10-23 15:43 ` Jeff Johnson
2024-10-26 9:09 ` Kalle Valo
2024-10-23 13:30 ` [PATCH 6/8] wifi: ath12k: add multi-link flag in peer create command Kalle Valo
2024-10-23 15:54 ` Jeff Johnson
2024-10-29 15:54 ` Kalle Valo
2024-10-29 16:01 ` Jeff Johnson
2024-10-29 16:04 ` Jeff Johnson
2024-11-01 14:06 ` Kalle Valo
2024-11-01 15:37 ` Jeff Johnson
2024-10-23 13:30 ` [PATCH 7/8] wifi: ath12k: add helper to find multi-link station Kalle Valo
2024-10-23 16:01 ` Jeff Johnson
2024-10-29 16:02 ` Kalle Valo
2024-11-01 14:33 ` Kalle Valo
2024-10-23 13:30 ` [PATCH 8/8] wifi: ath12k: Add MLO peer assoc command support Kalle Valo
2024-10-23 16:10 ` Jeff Johnson
2024-10-29 16:05 ` Kalle Valo
2024-10-29 16:10 ` Jeff Johnson
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=87frodfnsq.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_adisi@quicinc.com \
--cc=quic_jjohnson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox