Hi all,

Today's linux-next merge of the wireless-next tree got a conflict in:

  net/mac80211/mlme.c

between commit:

  035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G assoc")

from the origin tree and commit:

  f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc link")

from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/mac80211/mlme.c
index fa773f3b0541a,d577252dbb9f1..0000000000000
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@@ -7140,7 -7191,8 +7193,8 @@@ static void ieee80211_rx_mgmt_assoc_res
  {
  	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
  	struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
+ 	enum assoc_status assoc_status = ASSOC_ABANDON;
 -	u16 capab_info, status_code, aid;
 +	u16 capab_info, status_code, aid = 0;
  	struct ieee80211_elems_parse_params parse_params = {
  		.bss = NULL,
  		.link_id = -1,

Hi Mark,

Thanks for carrying the conflict resolution.

I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().

Commit 035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G
assoc") added:

	else if (status_code == WLAN_STATUS_SUCCESS)
		goto abandon_assoc;

where abandon_assoc destroyed the association data with ASSOC_ABANDON and
notified the driver.

After f13e573ab3f12 ("wifi: mac80211: notify driver before destroying
assoc link") folds the driver notification into
ieee80211_destroy_assoc_data(), the equivalent target is
destroy_assoc_data, since assoc_status is initialized to ASSOC_ABANDON.

next-20260722 instead has:

	else if (status_code == WLAN_STATUS_SUCCESS)
		goto notify_driver;

which bypasses ieee80211_destroy_assoc_data(). I believe this should
instead be:

	else if (status_code == WLAN_STATUS_SUCCESS)
		goto destroy_assoc_data;

Regards,
Zhao

On Wed, 22 Jul 2026 16:57:59 +0100, Mark Brown <broonie@kernel.org> wrote:
> Hi all,
>
> Today's linux-next merge of the wireless-next tree got a conflict in:
>
> net/mac80211/mlme.c
>
> between commit:
>
> 035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G assoc")
>
> from the origin tree and commit:
>
> f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc link")
>
> from the wireless-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc net/mac80211/mlme.c
> index fa773f3b0541a,d577252dbb9f1..0000000000000
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@@ -7140,7 -7191,8 +7193,8 @@@ static void ieee80211_rx_mgmt_assoc_res
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
> + enum assoc_status assoc_status = ASSOC_ABANDON;
> - u16 capab_info, status_code, aid;
> + u16 capab_info, status_code, aid = 0;
> struct ieee80211_elems_parse_params parse_params = {
> .bss = NULL,
> .link_id = -1,

On Wed, Jul 22, 2026 at 03:53:59PM -0500, Enderaoe Lyther wrote:

> Thanks for carrying the conflict resolution.
> 
> I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().
> 
> Commit 035ed430ce6a2 ("wifi: mac80211: avoid non-S1G AID fallback for S1G
> assoc") added:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto abandon_assoc;
> 
> where abandon_assoc destroyed the association data with ASSOC_ABANDON and
> notified the driver.
> 
> After f13e573ab3f12 ("wifi: mac80211: notify driver before destroying
> assoc link") folds the driver notification into
> ieee80211_destroy_assoc_data(), the equivalent target is
> destroy_assoc_data, since assoc_status is initialized to ASSOC_ABANDON.
> 
> next-20260722 instead has:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto notify_driver;
> 
> which bypasses ieee80211_destroy_assoc_data(). I believe this should
> instead be:
> 
> 	else if (status_code == WLAN_STATUS_SUCCESS)
> 		goto destroy_assoc_data;

I can't tell which bit of code you are talking about here.  I see there
is a block at line 7274 of -next:

        if (elems->aid_resp)
                aid = le16_to_cpu(elems->aid_resp->aid);
        else if (!assoc_data->s1g)
                aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
        else if (status_code == WLAN_STATUS_SUCCESS)
                goto notify_driver;

but that is immediately after another goto notify_driver, there's
further notify_driver error handling afterwards and all the earlier
error handling is return statements so it looks at least unclear what's
supposed to be going on.

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

On Thu, Jul 23, 2026 at 7:51 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 22, 2026 at 03:53:59PM -0500, Enderaoe Lyther wrote:
>
> > I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().
>
> I can't tell which bit of code you are talking about here.  I see there
> is a block at line 7274 of -next:
>
>         if (elems->aid_resp)
>                 aid = le16_to_cpu(elems->aid_resp->aid);
>         else if (!assoc_data->s1g)
>                 aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
>         else if (status_code == WLAN_STATUS_SUCCESS)
>                 goto notify_driver;

Sorry about the formatting in my earlier message. I should have quoted the
code inline instead of top-posting.

That last branch was introduced by 035ed430ce6a ("wifi: mac80211: avoid
non-S1G AID fallback for S1G assoc") as:

	else if (status_code == WLAN_STATUS_SUCCESS)
		goto abandon_assoc;

f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc
link") consolidated terminal association cleanup at destroy_assoc_data
and removed abandon_assoc. The conflict resolution retargeted this branch
to notify_driver, but notify_driver only calls drv_mgd_complete_tx()
without destroying the association data.

Since assoc_status is initialized to ASSOC_ABANDON at function entry, the
equivalent target is destroy_assoc_data. A successful S1G association
response with no AID Response element otherwise leaves assoc_data live
instead of abandoning it.

> but that is immediately after another goto notify_driver, there's
> further notify_driver error handling afterwards and all the earlier
> error handling is return statements so it looks at least unclear what's
> supposed to be going on.

Other goto notify_driver targets are intentional:

  - "if (!elems) goto notify_driver" is a pre-existing allocation failure
    bail-out; so association timeout handles cleanup.

  - The comeback path WLAN_STATUS_ASSOC_REJECTED_TEMPORARILY keeps
    assoc_data live deliberately for retry.

A successful S1G response without an AID Response element is terminal.
It needs to abandon association immediately, so the target should be
destroy_assoc_data rather than notify_driver.

> Please don't top post, reply in line with needed context.

Understood. Sorry for the unclear top-posted reply.

Zhao