Re: [PATCH wireless-next v4 10/21] wifi: nl80211/cfg80211: add support for querying SMD context for target AP MLD

[Pooventhiran G <pooventhiran.g@oss.qualcomm.com>]

On 11/11/2026 12:30 am, Johannes Berg wrote:
> On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
>>
>> +/**
>> + * struct cfg80211_smd_get_ctx_pending - pending async GET_SMD_CTX request
>> + * @list: linkage on wireless_dev::smd_get_ctx_pending_list
>> + * @sta_addr: non-AP MLD address for which context was requested
>> + * @dev_tracker: tracker object for the netdev referenced
>> + */
>> +struct cfg80211_smd_get_ctx_pending {
>> +	struct list_head list;
>> +	u8 sta_addr[ETH_ALEN];
>> +	netdevice_tracker dev_tracker;
>> +};
> 
> This seems ridiculous, if userspace sets the interface down it might get
> a stale response, but you're writing dozens of lines of code just to
> avoid _that_?
> 
> Maybe also to avoid querying the same STA twice but if the firmware
> can't cope with it then it can still reject it (or the driver), is there
> really a good reason to have all this complexity to prevent it?
> 
> Tracing on the output path, on the other hand, would be useful?
> 

Just the sta_addr alone helps identifying back-to-back requests for the same
STA and it is rejected in nl80211 itself.

The netdev reference is held to prevent invalid accesses to wdev/dev while
reporting the context back to userspace as there are no locks in this path and
another core may be servicing a DEL_INTERFACE unsynchronized with this context
report. Since the collated context report comes from atomic contexts, we
wouldn't be able to take wiphy_lock.

> johannes