linux-next: manual merge of the wireless-next tree with the wireless tree

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

Hi all,

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

  net/mac80211/rx.c

between commit:

  a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")

from the wireless tree and commit:

  fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/rx.c
index 3e2176a730e6,1c957194554b..000000000000
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@@ -2776,27 -2862,12 +2843,31 @@@ ieee80211_rx_mesh_data(struct ieee80211
  		rcu_read_unlock();
  	}
  
 +	/* Frame has reached destination.  Don't forward */
 +	if (ether_addr_equal(sdata->vif.addr, eth->h_dest))
 +		goto rx_accept;
 +
 +	if (!--mesh_hdr->ttl) {
 +		if (multicast)
 +			goto rx_accept;
 +
 +		IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
 +		return RX_DROP_MONITOR;
 +	}
 +
 +	if (!ifmsh->mshcfg.dot11MeshForwarding) {
 +		if (is_multicast_ether_addr(eth->h_dest))
 +			goto rx_accept;
 +
 +		return RX_DROP_MONITOR;
 +	}
 +
  	skb_set_queue_mapping(skb, ieee802_1d_to_ac[skb->priority]);
  
+ 	if (!multicast &&
+ 	    ieee80211_rx_mesh_fast_forward(sdata, skb, mesh_hdrlen))
+ 		return RX_QUEUED;
+ 
  	ieee80211_fill_mesh_addresses(&hdr, &hdr.frame_control,
  				      eth->h_dest, eth->h_source);
  	hdrlen = ieee80211_hdrlen(hdr.frame_control);
@@@ -2914,14 -2982,24 +2985,24 @@@ __ieee80211_rx_h_amsdu(struct ieee80211
  					  data_offset, true))
  		return RX_DROP_UNUSABLE;
  
 -	if (rx->sta && rx->sta->amsdu_mesh_control < 0) {
 +	if (rx->sta->amsdu_mesh_control < 0) {
- 		bool valid_std = ieee80211_is_valid_amsdu(skb, true);
- 		bool valid_nonstd = ieee80211_is_valid_amsdu(skb, false);
+ 		s8 valid = -1;
+ 		int i;
+ 
+ 		for (i = 0; i <= 2; i++) {
+ 			if (!ieee80211_is_valid_amsdu(skb, i))
+ 				continue;
+ 
+ 			if (valid >= 0) {
+ 				/* ambiguous */
+ 				valid = -1;
+ 				break;
+ 			}
  
- 		if (valid_std && !valid_nonstd)
- 			rx->sta->amsdu_mesh_control = 1;
- 		else if (valid_nonstd && !valid_std)
- 			rx->sta->amsdu_mesh_control = 0;
+ 			valid = i;
+ 		}
+ 
+ 		rx->sta->amsdu_mesh_control = valid;
  	}
  
  	ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Johannes Berg]

On Fri, 2023-03-31 at 10:49 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   net/mac80211/rx.c
> 
> between commit:
> 
>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
> 
> from the wireless tree and commit:
> 
>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
> 
> from the wireless-next tree.

Thanks for the heads-up. I sort of expected this, but didn't want to do
a merge or wireless into wireless-next before it was pulled, maybe I
should've staggered the pull requests, but you would've seen the merge
issue anyway.

Anyway, I've now pulled wireless into wireless-next, so you might
continue seeing this issue (*) if you merge net/net-next before merging
wireless-next, but it'll be completely resolved when we send the next
pull request to net-next (next week).

Thanks!

(*) and another one in nl80211 policy, I think?

joahnnes

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

Hi all,

On Fri, 31 Mar 2023 10:49:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   net/mac80211/rx.c
> 
> between commit:
> 
>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
> 
> from the wireless tree and commit:
> 
>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc net/mac80211/rx.c
> index 3e2176a730e6,1c957194554b..000000000000
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@@ -2776,27 -2862,12 +2843,31 @@@ ieee80211_rx_mesh_data(struct ieee80211
>   		rcu_read_unlock();
>   	}
>   
>  +	/* Frame has reached destination.  Don't forward */
>  +	if (ether_addr_equal(sdata->vif.addr, eth->h_dest))
>  +		goto rx_accept;
>  +
>  +	if (!--mesh_hdr->ttl) {
>  +		if (multicast)
>  +			goto rx_accept;
>  +
>  +		IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
>  +		return RX_DROP_MONITOR;
>  +	}
>  +
>  +	if (!ifmsh->mshcfg.dot11MeshForwarding) {
>  +		if (is_multicast_ether_addr(eth->h_dest))
>  +			goto rx_accept;
>  +
>  +		return RX_DROP_MONITOR;
>  +	}
>  +
>   	skb_set_queue_mapping(skb, ieee802_1d_to_ac[skb->priority]);
>   
> + 	if (!multicast &&
> + 	    ieee80211_rx_mesh_fast_forward(sdata, skb, mesh_hdrlen))
> + 		return RX_QUEUED;
> + 
>   	ieee80211_fill_mesh_addresses(&hdr, &hdr.frame_control,
>   				      eth->h_dest, eth->h_source);
>   	hdrlen = ieee80211_hdrlen(hdr.frame_control);
> @@@ -2914,14 -2982,24 +2985,24 @@@ __ieee80211_rx_h_amsdu(struct ieee80211
>   					  data_offset, true))
>   		return RX_DROP_UNUSABLE;
>   
>  -	if (rx->sta && rx->sta->amsdu_mesh_control < 0) {
>  +	if (rx->sta->amsdu_mesh_control < 0) {
> - 		bool valid_std = ieee80211_is_valid_amsdu(skb, true);
> - 		bool valid_nonstd = ieee80211_is_valid_amsdu(skb, false);
> + 		s8 valid = -1;
> + 		int i;
> + 
> + 		for (i = 0; i <= 2; i++) {
> + 			if (!ieee80211_is_valid_amsdu(skb, i))
> + 				continue;
> + 
> + 			if (valid >= 0) {
> + 				/* ambiguous */
> + 				valid = -1;
> + 				break;
> + 			}
>   
> - 		if (valid_std && !valid_nonstd)
> - 			rx->sta->amsdu_mesh_control = 1;
> - 		else if (valid_nonstd && !valid_std)
> - 			rx->sta->amsdu_mesh_control = 0;
> + 			valid = i;
> + 		}
> + 
> + 		rx->sta->amsdu_mesh_control = valid;
>   	}
>   
>   	ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,

This is now a conflict between the net-next and net trees.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Kalle Valo]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> On Fri, 31 Mar 2023 10:49:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the wireless-next tree got a conflict in:
>> 
>>   net/mac80211/rx.c
>> 
>> between commit:
>> 
>>   a16fc38315f2 ("wifi: mac80211: fix potential null pointer dereference")
>> 
>> from the wireless tree and commit:
>> 
>>   fe4a6d2db3ba ("wifi: mac80211: implement support for yet another mesh A-MSDU format")
>> 
>> 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.

[...]

> This is now a conflict between the net-next and net trees.

My plan is to submit wireless-next pull request to net-next by
Wednesday, that should fix the conflict.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

Hi all,

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

  net/mac80211/chan.c

between commit:

  89884459a0b9 ("wifi: mac80211: fix idle calculation with multi-link")

from the wireless tree and commit:

  87f5500285fb ("wifi: mac80211: simplify ieee80211_assign_link_chanctx()")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/chan.c
index 4e0c1a6e509f,dedf11eeb43c..380695fdc32f
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@@ -800,8 -819,7 +819,8 @@@ static int ieee80211_assign_link_chanct
  	struct ieee80211_local *local = sdata->local;
  	struct ieee80211_chanctx_conf *conf;
  	struct ieee80211_chanctx *curr_ctx = NULL;
 +	bool new_idle;
- 	int ret = 0;
+ 	int ret;
  
  	if (WARN_ON(sdata->vif.type == NL80211_IFTYPE_NAN))
  		return -EOPNOTSUPP;
@@@ -822,17 -840,24 +841,22 @@@
  		ieee80211_recalc_chanctx_min_def(local, new_ctx, link);
  
  		ret = drv_assign_vif_chanctx(local, sdata, link->conf, new_ctx);
- 		if (ret)
- 			goto out;
- 
- 		conf = &new_ctx->conf;
- 		list_add(&link->assigned_chanctx_list,
- 			 &new_ctx->assigned_links);
+ 		if (assign_on_failure || !ret) {
+ 			/* Need to continue, see _ieee80211_set_active_links */
+ 			WARN_ON_ONCE(ret && !local->in_reconfig);
+ 			ret = 0;
+ 
+ 			/* succeeded, so commit it to the data structures */
+ 			conf = &new_ctx->conf;
+ 			list_add(&link->assigned_chanctx_list,
+ 				 &new_ctx->assigned_links);
+ 		}
+ 	} else {
+ 		ret = 0;
  	}
  
- out:
  	rcu_assign_pointer(link->conf->chanctx_conf, conf);
  
 -	sdata->vif.cfg.idle = !conf;
 -
  	if (curr_ctx && ieee80211_chanctx_num_assigned(local, curr_ctx) > 0) {
  		ieee80211_recalc_chanctx_chantype(local, curr_ctx);
  		ieee80211_recalc_smps_chanctx(local, curr_ctx);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Johannes Berg]

Hi Stephen,

Thanks for the heads-up.

> between commit:
> 
>   5f4040050553 ("wifi: iwlwifi: mvm: disable MLO for the time being")
> 
> from the wireless tree and commit:
> 
>   bbd6d0f8bc51 ("wifi: iwlwifi: mvm: advertise IEEE80211_HW_HANDLES_QUIET_CSA")
> 
> from the wireless-next tree.

I kind of knew this was going to happen (given how the patches applied
or rather didn't), but nothing to prevent it yet. I think we'll get it
fixed in due time, before all the -next stuff goes anywhere.

Thanks,
johannes

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c

between commit:

  5f4040050553 ("wifi: iwlwifi: mvm: disable MLO for the time being")

from the wireless tree and commit:

  bbd6d0f8bc51 ("wifi: iwlwifi: mvm: advertise IEEE80211_HW_HANDLES_QUIET_CSA")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 8f4b063d6243,6b8f18b3e280..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@@ -359,8 -359,11 +359,11 @@@ int iwl_mvm_mac_setup_register(struct i
  	/* Set this early since we need to have it for the check below */
  	if (mvm->mld_api_is_used && mvm->nvm_data->sku_cap_11be_enable &&
  	    !iwlwifi_mod_params.disable_11ax &&
- 	    !iwlwifi_mod_params.disable_11be)
+ 	    !iwlwifi_mod_params.disable_11be) {
 -		hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_MLO;
 +		hw->wiphy->flags |= WIPHY_FLAG_DISABLE_WEXT;
+ 		/* we handle this already earlier, but need it for MLO */
+ 		ieee80211_hw_set(hw, HANDLES_QUIET_CSA);
+ 	}
  
  	/* With MLD FW API, it tracks timing by itself,
  	 * no need for any timing from the host

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Johannes Berg]

Hi,

Thanks for the heads-up!

On Fri, 2024-02-09 at 10:56 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-next tree got a conflict in:
> 
>   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> 
> between commit:
> 
>   2e57b77583ca ("wifi: iwlwifi: mvm: use correct address 3 in A-MSDU")
> 
> from the wireless tree and commit:
> 
>   3d869feacb74 ("wifi: iwlwifi: mvm: use FW rate for non-data only on new devices")

I had a different (potential) conflict on my radar and pulled wireless
into wireless-next to avoid it, but this one wasn't on my radar at all.
Sorry about that.

> I fixed it up (see below)

That obviously looks fine, thanks!

johannes

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/tx.c

between commit:

  2e57b77583ca ("wifi: iwlwifi: mvm: use correct address 3 in A-MSDU")

from the wireless tree and commit:

  3d869feacb74 ("wifi: iwlwifi: mvm: use FW rate for non-data only on new devices")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 461f26d9214e,4981bb1f0251..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@@ -520,16 -520,31 +520,41 @@@ static void iwl_mvm_set_tx_cmd_crypto(s
  	}
  }
  
 +static void iwl_mvm_copy_hdr(void *cmd, const void *hdr, int hdrlen,
 +			     const u8 *addr3_override)
 +{
 +	struct ieee80211_hdr *out_hdr = cmd;
 +
 +	memcpy(cmd, hdr, hdrlen);
 +	if (addr3_override)
 +		memcpy(out_hdr->addr3, addr3_override, ETH_ALEN);
 +}
 +
+ static bool iwl_mvm_use_host_rate(struct iwl_mvm *mvm,
+ 				  struct iwl_mvm_sta *mvmsta,
+ 				  struct ieee80211_hdr *hdr,
+ 				  struct ieee80211_tx_info *info)
+ {
+ 	if (unlikely(!mvmsta))
+ 		return true;
+ 
+ 	if (unlikely(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT))
+ 		return true;
+ 
+ 	if (likely(ieee80211_is_data(hdr->frame_control) &&
+ 		   mvmsta->sta_state >= IEEE80211_STA_AUTHORIZED))
+ 		return false;
+ 
+ 	/*
+ 	 * Not a data frame, use host rate if on an old device that
+ 	 * can't possibly be doing MLO (firmware may be selecting a
+ 	 * bad rate), if we might be doing MLO we need to let FW pick
+ 	 * (since we don't necesarily know the link), but FW rate
+ 	 * selection was fixed.
+ 	 */
+ 	return mvm->trans->trans_cfg->device_family < IWL_DEVICE_FAMILY_BZ;
+ }
+ 
  /*
   * Allocates and sets the Tx cmd the driver data pointers in the skb
   */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Johannes Berg]

On Tue, 2023-09-26 at 12:41 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 26 Sep 2023 12:02:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > Today's linux-next merge of the wireless-next tree got conflicts in:
> > 
> >   net/mac80211/cfg.c
> > 
> > between commit:
> > 
> >   31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
> > 
> > from the wireless tree and commit:
> > 
> >   4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")
> > 
> > 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.
> 
> That wasn't quite right.  The final resolution is below.

Thanks Stephen, also for the other one!

I knew about the new ones as well but forgot to give you a heads-up, my
bad, I'm sorry.

I'm planning to submit a wireless pull request today or tomorrow, and
then merge back into wireless-next once it settles in, so this should
hopefully be resolved by the end of the week or so.

Thanks,
johannes

Re: linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Hi all,

On Tue, 26 Sep 2023 12:02:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the wireless-next tree got conflicts in:
> 
>   net/mac80211/cfg.c
> 
> between commit:
> 
>   31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
> 
> from the wireless tree and commit:
> 
>   4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")
> 
> 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.

That wasn't quite right.  The final resolution is below.
-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/cfg.c
index 0e3a1753a51c,5bc6b1329465..3e7bb883137c
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@@ -472,8 -470,9 +470,10 @@@ static int ieee80211_add_key(struct wip
  	struct ieee80211_local *local = sdata->local;
  	struct sta_info *sta = NULL;
  	struct ieee80211_key *key;
 +	int err;
  
+ 	lockdep_assert_wiphy(local->hw.wiphy);
+ 
  	if (!ieee80211_sdata_running(sdata))
  		return -ENETDOWN;
  
@@@ -565,15 -561,7 +562,11 @@@
  		break;
  	}
  
 -	return ieee80211_key_link(key, link, sta);
 +	err = ieee80211_key_link(key, link, sta);
 +	/* KRACK protection, shouldn't happen but just silently accept key */
 +	if (err == -EALREADY)
 +		err = 0;
- 
-  out_unlock:
- 	mutex_unlock(&local->sta_mtx);
- 
 +	return err;
  }
  
  static struct ieee80211_key *

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

Hi all,

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

  net/mac80211/key.c

between commits:

  31db78a4923e ("wifi: mac80211: fix potential key use-after-free")
  d097ae01ebd4 ("wifi: mac80211: fix potential key leak")

from the wireless tree and commit:

  2a8b665e6bcc ("wifi: mac80211: remove key_mtx")

from the wireless-next tree.

I fixed it up (I think - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/key.c
index 0665ff5e456e,ac410f6632b5..000000000000
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@@ -881,21 -875,20 +880,22 @@@ int ieee80211_key_link(struct ieee80211
  
  		if (link_id >= 0) {
  			link_sta = rcu_dereference_protected(sta->link[link_id],
- 							     lockdep_is_held(&sta->local->sta_mtx));
+ 							     lockdep_is_held(&sta->local->hw.wiphy->mtx));
 -			if (!link_sta)
 -				return -ENOLINK;
 +			if (!link_sta) {
 +				ret = -ENOLINK;
 +				goto out;
 +			}
  		}
  
- 		old_key = key_mtx_dereference(sdata->local, link_sta->gtk[idx]);
+ 		old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 					    link_sta->gtk[idx]);
  	} else {
  		if (idx < NUM_DEFAULT_KEYS)
- 			old_key = key_mtx_dereference(sdata->local,
- 						      sdata->keys[idx]);
+ 			old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 						    sdata->keys[idx]);
  		if (!old_key)
- 			old_key = key_mtx_dereference(sdata->local,
- 						      link->gtk[idx]);
+ 			old_key = wiphy_dereference(sdata->local->hw.wiphy,
+ 						    link->gtk[idx]);
  	}
  
  	/* Non-pairwise keys must also not switch the cipher on rekey */
@@@ -910,10 -901,10 +910,8 @@@
  	 * Silently accept key re-installation without really installing the
  	 * new version of the key to avoid nonce reuse or replay issues.
  	 */
--	if (ieee80211_key_identical(sdata, old_key, key)) {
- 		ret = -EALREADY;
- 		goto unlock;
 -		ieee80211_key_free_unused(key);
 -		return 0;
--	}
++	if (ieee80211_key_identical(sdata, old_key, key))
++		return -EALREADY;
  
  	key->local = sdata->local;
  	key->sdata = sdata;
@@@ -936,13 -927,6 +934,10 @@@
  		ieee80211_key_free(key, delay_tailroom);
  	}
  
 +	key = NULL;
 +
 + out:
 +	ieee80211_key_free_unused(key);
-  unlock:
- 	mutex_unlock(&sdata->local->key_mtx);
- 
  	return ret;
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

Hi all,

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

  net/mac80211/cfg.c

between commit:

  31db78a4923e ("wifi: mac80211: fix potential key use-after-free")

from the wireless tree and commit:

  4d3acf4311a0 ("wifi: mac80211: remove sta_mtx")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/cfg.c
index 0e3a1753a51c,5bc6b1329465..000000000000
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@@ -565,15 -561,7 +561,11 @@@ static int ieee80211_add_key(struct wip
  		break;
  	}
  
 -	return ieee80211_key_link(key, link, sta);
 +	err = ieee80211_key_link(key, link, sta);
 +	/* KRACK protection, shouldn't happen but just silently accept key */
 +	if (err == -EALREADY)
 +		err = 0;
- 
-  out_unlock:
- 	mutex_unlock(&local->sta_mtx);
- 
 +	return err;
  }
  
  static struct ieee80211_key *

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5267 bytes --]

Hi all,

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

  net/wireless/nl80211.c

between commit:

  37c20b2effe9 ("wifi: cfg80211: fix cqm_config access race")

from the wireless tree and commit:

  076fc8775daf ("wifi: cfg80211: remove wdev mutex")

from the wireless-next tree.

I fixed it up (I used a supplied resolution from Johannes - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/wireless/nl80211.c
index 7a88361b3414,ab0aea7dca7d..fe06c238d4ef
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -6191,12 -6135,8 +6150,12 @@@ static int nl80211_start_ap(struct sk_b
  
  	err = nl80211_calculate_ap_params(params);
  	if (err)
- 		goto out_unlock;
+ 		goto out;
  
 +	err = nl80211_validate_ap_phy_operation(params);
 +	if (err)
- 		goto out_unlock;
++		goto out;
 +
  	if (info->attrs[NL80211_ATTR_AP_SETTINGS_FLAGS])
  		params->flags = nla_get_u32(
  			info->attrs[NL80211_ATTR_AP_SETTINGS_FLAGS]);
@@@ -12884,11 -12747,10 +12767,11 @@@ static int nl80211_set_cqm_rssi(struct 
  				u32 hysteresis)
  {
  	struct cfg80211_registered_device *rdev = info->user_ptr[0];
 +	struct cfg80211_cqm_config *cqm_config = NULL, *old;
  	struct net_device *dev = info->user_ptr[1];
  	struct wireless_dev *wdev = dev->ieee80211_ptr;
- 	int i, err;
  	s32 prev = S32_MIN;
 -	int i;
++	int i, err;
  
  	/* Check all values negative and sorted */
  	for (i = 0; i < n_thresholds; i++) {
@@@ -12917,11 -12781,9 +12800,9 @@@
  	if (n_thresholds == 1 && thresholds[0] == 0) /* Disabling */
  		n_thresholds = 0;
  
- 	wdev_lock(wdev);
- 	old = rcu_dereference_protected(wdev->cqm_config,
- 					lockdep_is_held(&wdev->mtx));
 -	if (n_thresholds) {
 -		struct cfg80211_cqm_config *cqm_config;
++	old = wiphy_dereference(wdev->wiphy, wdev->cqm_config);
  
 +	if (n_thresholds) {
  		cqm_config = kzalloc(struct_size(cqm_config, rssi_thresholds,
  						 n_thresholds),
  				     GFP_KERNEL);
@@@ -12936,22 -12796,10 +12815,20 @@@
  		       flex_array_size(cqm_config, rssi_thresholds,
  				       n_thresholds));
  
 -		wdev->cqm_config = cqm_config;
 +		rcu_assign_pointer(wdev->cqm_config, cqm_config);
 +	} else {
 +		RCU_INIT_POINTER(wdev->cqm_config, NULL);
  	}
  
 -	return cfg80211_cqm_rssi_update(rdev, dev);
 +	err = cfg80211_cqm_rssi_update(rdev, dev, cqm_config);
 +	if (err) {
 +		rcu_assign_pointer(wdev->cqm_config, old);
 +		kfree_rcu(cqm_config, rcu_head);
 +	} else {
 +		kfree_rcu(old, rcu_head);
 +	}
- unlock:
- 	wdev_unlock(wdev);
 +
 +	return err;
  }
  
  static int nl80211_set_cqm(struct sk_buff *skb, struct genl_info *info)
@@@ -19107,41 -18879,18 +18907,39 @@@ void cfg80211_cqm_rssi_notify(struct ne
  		    rssi_event != NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH))
  		return;
  
 -	if (wdev->cqm_config) {
 -		wdev->cqm_config->last_rssi_event_value = rssi_level;
 +	rcu_read_lock();
 +	cqm_config = rcu_dereference(wdev->cqm_config);
 +	if (cqm_config) {
 +		cqm_config->last_rssi_event_value = rssi_level;
 +		cqm_config->last_rssi_event_type = rssi_event;
 +		wiphy_work_queue(wdev->wiphy, &wdev->cqm_rssi_work);
 +	}
 +	rcu_read_unlock();
 +}
 +EXPORT_SYMBOL(cfg80211_cqm_rssi_notify);
 +
 +void cfg80211_cqm_rssi_notify_work(struct wiphy *wiphy, struct wiphy_work *work)
 +{
 +	struct wireless_dev *wdev = container_of(work, struct wireless_dev,
 +						 cqm_rssi_work);
 +	struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
 +	enum nl80211_cqm_rssi_threshold_event rssi_event;
 +	struct cfg80211_cqm_config *cqm_config;
 +	struct sk_buff *msg;
 +	s32 rssi_level;
 +
- 	wdev_lock(wdev);
- 	cqm_config = rcu_dereference_protected(wdev->cqm_config,
- 					       lockdep_is_held(&wdev->mtx));
++	cqm_config = wiphy_dereference(wdev->wiphy, wdev->cqm_config);
 +	if (!wdev->cqm_config)
- 		goto unlock;
++		return;
  
 -		cfg80211_cqm_rssi_update(rdev, dev);
 +	cfg80211_cqm_rssi_update(rdev, wdev->netdev, cqm_config);
  
 -		if (rssi_level == 0)
 -			rssi_level = wdev->cqm_config->last_rssi_event_value;
 -	}
 +	rssi_level = cqm_config->last_rssi_event_value;
 +	rssi_event = cqm_config->last_rssi_event_type;
  
 -	msg = cfg80211_prepare_cqm(dev, NULL, gfp);
 +	msg = cfg80211_prepare_cqm(wdev->netdev, NULL, GFP_KERNEL);
  	if (!msg)
- 		goto unlock;
+ 		return;
  
  	if (nla_put_u32(msg, NL80211_ATTR_CQM_RSSI_THRESHOLD_EVENT,
  			rssi_event))
@@@ -19151,15 -18900,14 +18949,13 @@@
  				      rssi_level))
  		goto nla_put_failure;
  
 -	cfg80211_send_cqm(msg, gfp);
 +	cfg80211_send_cqm(msg, GFP_KERNEL);
  
- 	goto unlock;
+ 	return;
  
   nla_put_failure:
  	nlmsg_free(msg);
-  unlock:
- 	wdev_unlock(wdev);
  }
 -EXPORT_SYMBOL(cfg80211_cqm_rssi_notify);
  
  void cfg80211_cqm_txe_notify(struct net_device *dev,
  			     const u8 *peer, u32 num_packets,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]