All of lore.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2024-10-30 18:28 UTC|newest]

Thread overview: 39+ 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-24  1:22   ` Ping-Ke Shih
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 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.