Re: [PATCH] net: wireless: ath: ath10k: remove unnecessary code

[Kalle Valo]

"Gustavo A. R. Silva"  writes:

> The name of an array used by itself will always return the array's address.
> So these tests will always evaluate as false and therefore the _return_
> will never be executed.
>
> Signed-off-by: Gustavo A. R. Silva 

I don't understand the commit log, especially what does "The name of an
array used by itself" mean?

-- 
Kalle Valo

[PATCH] net: wireless: ath: ath10k: remove unnecessary code

[Gustavo A. R. Silva]

The name of an array used by itself will always return the array's address.
So these tests will always evaluate as false and therefore the _return_
will never be executed.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2f1743e..135cf83 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5933,15 +5933,6 @@ static struct sk_buff 
*ath10k_wmi_10_4_op_gen_init(struct ath10k *ar)
 
 int ath10k_wmi_start_scan_verify(const struct wmi_start_scan_arg *arg)
 {
-   if (arg->ie_len && !arg->ie)
-   return -EINVAL;
-   if (arg->n_channels && !arg->channels)
-   return -EINVAL;
-   if (arg->n_ssids && !arg->ssids)
-   return -EINVAL;
-   if (arg->n_bssids && !arg->bssids)
-   return -EINVAL;
-
if (arg->ie_len > WLAN_SCAN_PARAMS_MAX_IE_LEN)
return -EINVAL;
if (arg->n_channels > ARRAY_SIZE(arg->channels))
-- 
2.5.0

[PATCH] wcn36xx: Close SMD channel on device removal

[Bjorn Andersson]

The SMD channel is not the primary WCNSS channel and must explicitly be
closed as the device is removed, or the channel will already by open on
a subsequent probe call in e.g. the case of reloading the kernel module.

This issue was introduced because I simplified the underlying SMD
implementation while the SMD adaptions of the driver sat on the mailing
list, but missed to update these patches. The patch does however only
apply back to the transition to rpmsg, hence the limited Fixes.

Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to 
rpmsg")
Reported-by: Eyal Ilsar 
Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index d5e993dc9b23..517a315e259b 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1271,6 +1271,8 @@ static int wcn36xx_remove(struct platform_device *pdev)
qcom_smem_state_put(wcn->tx_enable_state);
qcom_smem_state_put(wcn->tx_rings_empty_state);
 
+   rpmsg_destroy_ept(wcn->smd_channel);
+
iounmap(wcn->dxe_base);
iounmap(wcn->ccu_base);
 
-- 
2.12.0

[PATCH] net: wireless: ath: ath9k: remove unnecessary code

[Gustavo A. R. Silva]

The name of an array used by itself will always return the array's address.
So this test will always evaluate as true.

Addresses-Coverity-ID: 1364903
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index fb80ec8..5c3bc28 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -143,7 +143,7 @@ bool ath9k_hw_nvram_read(struct ath_hw *ah, u32 off, u16 
*data)
 
if (ah->eeprom_blob)
ret = ath9k_hw_nvram_read_firmware(ah->eeprom_blob, off, data);
-   else if (pdata && !pdata->use_eeprom && pdata->eeprom_data)
+   else if (pdata && !pdata->use_eeprom)
ret = ath9k_hw_nvram_read_pdata(pdata, off, data);
else
ret = common->bus_ops->eeprom_read(common, off, data);
-- 
2.5.0

[PATCH] drivers: net: wireless: rsi: rsi_91x_core: Use time_after time comparison

[Karim Eshapa]

Use time_after kernel macro for time comparison.

Signed-off-by: Karim Eshapa 
---
 drivers/net/wireless/rsi/rsi_91x_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c 
b/drivers/net/wireless/rsi/rsi_91x_core.c
index f3d3995..68f04a7 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -306,7 +306,7 @@ void rsi_core_qos_processor(struct rsi_common *common)
tstamp_2 = jiffies;
mutex_unlock(>tx_rxlock);
 
-   if (tstamp_2 > tstamp_1 + (300 * HZ / 1000))
+   if (time_after(tstamp_2, tstamp_1 + (300 * HZ) / 1000))
schedule();
}
 }
-- 
2.7.4

Re: pull-request: mac80211 2017-05-08

[David Miller]

From: Johannes Berg 
Date: Mon,  8 May 2017 16:46:21 +0200

> Thanks for merging the rate fix quickly the other day. I've got a
> few more fixes lined up, so this time as a pull request.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks.

Ath10k Firmware crashes on QCA9888 board

[Joan Josep]

Hello everybody

We bought some 11AC cards and we experienced some issues.

We are using a qca9888 chipset 11AC mini pci card on a 4.9.0 kernel 
compiled for an ARM processor (imx6) using Ubuntu 14.04 as operating system.


We are experiencing some problems when we try to load the ath10k_pci 
kernel module to use this card.


This is the resulting dmesg:

--> $ modprobe ath10k_pci

[   48.623361] ath10k_pci :07:00.0: enabling bus mastering
[   48.624103] ath10k_pci :07:00.0: pci irq msi oper_irq_mode 2 
irq_mode 0 reset_mode 0

[   48.697892] imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
[   48.704523] imx-sgtl5000 sound: snd_soc_register_card failed (-517)
[   48.798971] ath10k_pci :07:00.0: Direct firmware load for 
ath10k/pre-cal-pci-:07:00.0.bin failed with error -2
[   48.799002] ath10k_pci :07:00.0: Direct firmware load for 
ath10k/cal-pci-:07:00.0.bin failed with error -2
[   48.800225] ath10k_pci :07:00.0: qca9888 hw2.0 target 0x0100 
chip_id 0x sub :
[   48.800236] ath10k_pci :07:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   48.802878] ath10k_pci :07:00.0: firmware ver 10.4-3.2-00072 api 
5 features no-p2p,mfp,peer-flow-ctrl crc32 b1da0716
[   50.789954] ath10k_pci :07:00.0: board_file api 2 bmi_id 0:17 
crc32 74a04250


-- wlan0 appears on the system.

--> $ ifconfig wlan0 up


[   54.243525] ath10k_pci :07:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 
cal otp max-sta 512 raw 0 hwcrypto 1
[   54.250981] ath10k_pci :07:00.0: firmware crashed! (uuid 
bf8aea5c-18bb-4433-b6a0-28143d0bae33)
[   54.259971] ath10k_pci :07:00.0: qca9888 hw2.0 target 0x0100 
chip_id 0x sub :
[   54.259980] ath10k_pci :07:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   54.262670] ath10k_pci :07:00.0: firmware ver 10.4-3.2-00072 api 
5 features no-p2p,mfp,peer-flow-ctrl crc32 b1da0716
[   54.263023] ath10k_pci :07:00.0: board_file api 2 bmi_id 0:17 
crc32 74a04250
[   54.263032] ath10k_pci :07:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 
cal otp max-sta 512 raw 0 hwcrypto 1
[   54.275070] ath10k_pci :07:00.0: failed to get memcpy hi address 
for firmware address 4: -16
[   54.275077] ath10k_pci :07:00.0: failed to read firmware dump 
area: -16

[   54.339879] ath: EEPROM regdomain: 0x0
[   54.339886] ath: EEPROM indicates default country code should be used
[   54.339888] ath: doing EEPROM country->regdmn map search
[   54.339895] ath: country maps to regdmn code: 0x3a
[   54.339898] ath: Country alpha2 being used: US
[   54.339902] ath: Regpair used: 0x3a
[   54.407533] ath10k_pci :07:00.0: cannot restart a device that 
hasn't been started

[   58.528359] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   63.047527] random: crng init done

-- wlan0 is still on the system but not responding anymore.


Could you please give us any help on this?

Thank you

Joan Josep

Re: [PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

On 9 May 2017 at 00:42, Andy Shevchenko  wrote:
> On Sun, May 7, 2017 at 1:04 PM, Ian W MORRISON  wrote:



>
> What are you trying to achieve by posting this patch over and over so often?
>
> Version 5 look pretty good to me. Just stop posting it again and wait
> when Greg takes it.
>

I made a series of errors in the patch submission due to inexperience
in submitting my very first patch. The visibility of my minor mistakes
in certainly not what I would have liked and I can only apologize for
the annoyance caused. I believe I have finally corrected the patch to
meet the exacting standards required and having learnt from the
experience I hope never to repeat them.

> FWIW (version 5!):
> Reviewed-by: Andy Shevchenko 
>
> --
> With Best Regards,
> Andy Shevchenko

Thank you for your review,
Ian

pull-request: mac80211 2017-05-08

[Johannes Berg]

Hi Dave,

Thanks for merging the rate fix quickly the other day. I've got a
few more fixes lined up, so this time as a pull request.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 4ac4d584886a4f47f8ff3bca0f32ff9a2987d3e5:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-05-04 
12:26:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2017-05-08

for you to fetch changes up to 6406c91943a0f29b6e8786921aaa038663e08055:

  cfg80211: fix multi scheduled scan kernel-doc (2017-05-08 13:09:38 +0200)


A couple more fixes:
 * don't try to authenticate during reconfiguration, which causes
   drivers to get confused
 * fix a kernel-doc warning for a recently merged change
 * fix MU-MIMO group configuration (relevant only for monitor mode)
 * more rate flags fix: remove stray RX_ENC_FLAG_40MHZ
 * fix IBSS probe response allocation size


Johannes Berg (4):
  mac80211: properly remove RX_ENC_FLAG_40MHZ
  nl80211: correctly validate MU-MIMO groups
  mac80211: fix IBSS presp allocation size
  cfg80211: fix multi scheduled scan kernel-doc

Luca Coelho (1):
  mac80211: bail out from prep_connection() if a reconfig is ongoing

 drivers/net/wireless/ath/ath9k/ar9003_mac.c| 2 +-
 drivers/net/wireless/ath/ath9k/mac.c   | 4 ++--
 drivers/net/wireless/intel/iwlegacy/4965-mac.c | 4 +++-
 drivers/net/wireless/intel/iwlwifi/dvm/rx.c| 4 +++-
 drivers/net/wireless/mac80211_hwsim.c  | 8 +++-
 include/net/cfg80211.h | 2 +-
 include/net/mac80211.h | 2 --
 net/mac80211/ibss.c| 2 ++
 net/mac80211/mlme.c| 4 
 net/wireless/nl80211.c | 4 ++--
 10 files changed, 25 insertions(+), 11 deletions(-)

Re: [PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Andy Shevchenko]

On Sun, May 7, 2017 at 1:04 PM, Ian W MORRISON  wrote:
> A kernel cloned from
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and
> built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m)
> fails when booting on an Intel Atom device with the RTL8723BS wifi
> chipset due to an error in
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.
>
> The kernel when booted with Ubuntu 17.04 results in an unusable system
> however with the following patch booting is successful and the system
> is usable. The patch and kernel builds have been tested against on an
> Intel Compute Stick (STCK1A32WFC model).
>
> This version of the patch (version 5) has tabs rather than spaces, no
> wrap around, a changelog and a sign-off email.

What are you trying to achieve by posting this patch over and over so often?

Version 5 look pretty good to me. Just stop posting it again and wait
when Greg takes it.

FWIW (version 5!):
Reviewed-by: Andy Shevchenko 

-- 
With Best Regards,
Andy Shevchenko

Re: mwifiex won't connect to WPA2 anymore

[Dan Williams]

On Sat, 2017-05-06 at 22:22 +0200, Julien Cubizolles wrote:
> Dan Williams  writes:
> 
> 
> > Ok, at this point the only thing I can think of is the MAC
> > randomization that NM has.  Please see:
> > 
> > https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-
> > networkmanager-1-4-0/
> > 
> > and look at the section "Randomization during Wi-Fi scanning" where
> > it
> > says:
> > 
> > 
> > This default behavior can be disabled with a global configuration
> > option in NetworkManager.conf:
> > 
> > [device]
> > wifi.scan-rand-mac-address=no
> > 
> > 
> > if you set that, and restart NetworkManager, does that magically
> > make
> > things work?
> 
> Yes! It's now working fine, thanks a lot. I have my wifi AP set to
> only
> accept a whitelist of MAC addresses so it makes sense that I can't
> connect if the MAC address is random. I'll disable the randomization
> for
> now on.

Well, ideally you wouldn't have to do this, but we haven't quite
figured out whether it's a bug in the way NM does randomization or
whether the drivers that require this switch (there are a few) are just
broken somehow.

Dan

[PATCH v6] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A re-positioned call to kfree() in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
causes a segmentation error. This patch removed the kfree() call.

Fixes 6557ddfec348 ("staging: rtl8723bs: Fix various errors in 
os_dep/ioctl_cfg80211.c")
Signed-off-by: Ian W Morrison 
Reviewed-by: Hans de Goede 
---
This version of the patch (version 6) fixes errors in the patch submission.
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH] iwlwifi: fix merge damage in iwl_req_fw_callback()

[Luca Coelho]

From: Luca Coelho 

A merge damage happened when applying commit 06a1e85e66ba ("iwlwifi:
remove module loading failure message") from our internal tree to
iwlwifi-next.git.  Fix it.

Fixes: 06a1e85e66ba ("iwlwifi: remove module loading failure message")
Reported-by: Pavel Roskin 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 5cfacb0bca84..5087ca3c848d 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1493,15 +1493,8 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
 * else from proceeding if the module fails to load
 * or hangs loading.
 */
-   if (load_module) {
+   if (load_module)
request_module("%s", op->name);
-#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
-   if (err)
-   IWL_ERR(drv,
-   "failed to load module %s (error %d), is 
dynamic loading enabled?\n",
-   op->name, err);
-#endif
-   }
goto free;
 
  try_again:
-- 
2.11.0

mwifiex_pcie does not recover after suspend

[Maxime Vincent]

I am running the latest linux-next wireless stack, backported on 4.4,
including the latest mwifiex patches that have been posted on this
mailing list. (thanks!)
Latest patch I applied is "mwifiex: pcie: add card_reset() support"
from Brian Norris.

I am running this kernel on a Microsoft Surface Pro 4.

After suspending (to disk) and resuming, the relevant dmesg output is:
[  158.094407] Restarting tasks ...
[  158.096470] usb 1-5: USB disconnect, device number 3
[  158.096515] done.
[  158.097137] ieee80211 phy0: sched_scan start : n_ssids=1 n_match_sets=1
[  158.097144] ieee80211 phy0: n_channels=41 interval=10 ie_len=126
[  168.118775] mwifiex_pcie :02:00.0: mwifiex_cmd_timeout_func:
Timeout cmd id = 0x6b, act = 0x1
[  168.118797] mwifiex_pcie :02:00.0: num_data_h2c_failure = 0
[  168.118804] mwifiex_pcie :02:00.0: num_cmd_h2c_failure = 0
[  168.118810] mwifiex_pcie :02:00.0: is_cmd_timedout = 1
[  168.118816] mwifiex_pcie :02:00.0: num_tx_timeout = 0
[  168.118822] mwifiex_pcie :02:00.0: last_cmd_index = 1
[  168.118829] mwifiex_pcie :02:00.0: last_cmd_id: e5 00 6b 00 28
00 28 00 28 00
[  168.118835] mwifiex_pcie :02:00.0: last_cmd_act: 01 00 01 00 13
00 13 00 13 00
[  168.118841] mwifiex_pcie :02:00.0: last_cmd_resp_index = 0
[  168.118848] mwifiex_pcie :02:00.0: last_cmd_resp_id: e5 80 28
80 28 80 28 80 28 80
[  168.118854] mwifiex_pcie :02:00.0: last_event_index = 2
[  168.118860] mwifiex_pcie :02:00.0: last_event: 0b 00 0a 00 0a
00 58 00 58 00
[  168.118866] mwifiex_pcie :02:00.0: data_sent=0 cmd_sent=1
[  168.118873] mwifiex_pcie :02:00.0: ps_mode=1 ps_state=0
[  168.120902] ieee80211 phy0: sched_scan start : n_ssids=1 n_match_sets=1
[  168.120914] ieee80211 phy0: n_channels=41 interval=10 ie_len=126
[  168.120925] mwifiex_pcie :02:00.0: PREP_CMD: FW is in bad state
[  168.121770] mwifiex_pcie :02:00.0: Ignore scan. Card removed or
firmware in bad state
[  168.121780] mwifiex_pcie :02:00.0: scan failed: -14
[  168.125201] mwifiex_pcie :02:00.0: ===mwifiex driverinfo dump start===
[  168.125278] mwifiex_pcie :02:00.0: info: MWIFIEX VERSION:
mwifiex 1.0 (15.68.7.p77)
[  168.125288] mwifiex_pcie :02:00.0: PCIE register dump start
[  168.125382] mwifiex_pcie :02:00.0: pcie scratch register:
[  168.125392] mwifiex_pcie :02:00.0: reg:0xcf0, value=0x0
   reg:0xcf8, value=0x0
   reg:0xcfc, value=0x0

[  168.125395] mwifiex_pcie :02:00.0: PCIE register dump end
[  168.125433] mwifiex_pcie :02:00.0: ===mwifiex driverinfo dump end===
[  168.125436] mwifiex_pcie :02:00.0: == mwifiex firmware dump start ==
[  168.156435] mwifiex_pcie :02:00.0: Fail to pull ctrl_data
[  168.156469] mwifiex_pcie :02:00.0: == mwifiex dump information
to /sys/class/devcoredump start
[  168.156548] mwifiex_pcie :02:00.0: == mwifiex dump information
to /sys/class/devcoredump end
[  168.156728] mwifiex_pcie :02:00.0: info: shutdown mwifiex...
[  168.157429] mwifiex_pcie :02:00.0: PREP_CMD: card is removed
[  168.157437] mwifiex_pcie :02:00.0: PREP_CMD: card is removed
[  169.282762] mwifiex_pcie :02:00.0: FW CRC error indicated by
the helper: len = 0x0011, txlen = 17
[  169.282784] mwifiex_pcie :02:00.0: Invalid parameter in
mwifiex_pcie_send_boot_cmd 
[  169.282786] mwifiex_pcie :02:00.0: Failed to send firmware
download command
[  169.282794] mwifiex_pcie :02:00.0: prog_fw failed ret=0x
[  169.282801] mwifiex_pcie :02:00.0: info: _mwifiex_fw_dpc:
unregister device


 I am willing to do some experiments, by modifying the driver myself,
but need some pointers on where to look, or what to try. Would
downloading the firmware to the controller again help?

Any help is welcome! Thanks.

Maxime Vincent

[PATCH] nl80211: correctly validate MU-MIMO groups

[Johannes Berg]

From: Johannes Berg 

Since groups 0 and 63 are invalid, we should check for those bits.
Note that the 802.11 spec specifies the *bit* order, but the CPU
doesn't care about bit order since it can't address bits, so it's
always treating BIT(0) as the lowest bit within a byte.

Reported-by: Jan Fuchs 
Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 570fc95dc507..c3bc9da30cff 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2764,8 +2764,8 @@ static int nl80211_parse_mon_options(struct 
cfg80211_registered_device *rdev,
nla_data(info->attrs[NL80211_ATTR_MU_MIMO_GROUP_DATA]);
 
/* bits 0 and 63 are reserved and must be zero */
-   if ((mumimo_groups[0] & BIT(7)) ||
-   (mumimo_groups[VHT_MUMIMO_GROUPS_DATA_LEN - 1] & BIT(0)))
+   if ((mumimo_groups[0] & BIT(0)) ||
+   (mumimo_groups[VHT_MUMIMO_GROUPS_DATA_LEN - 1] & BIT(7)))
return -EINVAL;
 
params->vht_mumimo_groups = mumimo_groups;
-- 
2.11.0

[PATCH] mac80211: fix IBSS presp allocation size

[Johannes Berg]

From: Johannes Berg 

When VHT IBSS support was added, the size of the extra elements
wasn't considered in ieee80211_ibss_build_presp(), which makes
it possible that it would overrun the allocated buffer. Fix it
by allocating the necessary space.

Fixes: abcff6ef01f9 ("mac80211: add VHT support for IBSS")
Reported-by: Shaul Triebitz 
Signed-off-by: Johannes Berg 
---
 net/mac80211/ibss.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 6db09fa18269..364d4e137649 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -66,6 +66,8 @@ ieee80211_ibss_build_presp(struct ieee80211_sub_if_data 
*sdata,
2 + (IEEE80211_MAX_SUPP_RATES - 8) +
2 + sizeof(struct ieee80211_ht_cap) +
2 + sizeof(struct ieee80211_ht_operation) +
+   2 + sizeof(struct ieee80211_vht_cap) +
+   2 + sizeof(struct ieee80211_vht_operation) +
ifibss->ie_len;
presp = kzalloc(sizeof(*presp) + frame_len, GFP_KERNEL);
if (!presp)
-- 
2.11.0

[PATCH] mac80211: bail out from prep_connection() if a reconfig is ongoing

[Johannes Berg]

From: Luca Coelho 

If ieee80211_hw_restart() is called during authentication, the
authentication process will continue, causing the driver to be called
in a wrong state.  This ultimately causes an oops in the iwlwifi
driver (at least).

This fixes bugzilla 195299 partly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195299
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
---
 net/mac80211/mlme.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 89dff563b1ec..0ea9712bd99e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4382,6 +4382,10 @@ static int ieee80211_prep_connection(struct 
ieee80211_sub_if_data *sdata,
if (WARN_ON(!ifmgd->auth_data && !ifmgd->assoc_data))
return -EINVAL;
 
+   /* If a reconfig is happening, bail out */
+   if (local->in_reconfig)
+   return -EBUSY;
+
if (assoc) {
rcu_read_lock();
have_sta = sta_info_get(sdata, cbss->bssid);
-- 
2.11.0

Re: iwlwifi 8260 crash (4.11rc6)

[Luca Coelho]

Hi,

On Sat, 2017-05-06 at 08:39 +0200, Janusz Dziedzic wrote:
> 4.11.0-rc6-next-20170413+
> 04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
> iwlwifi :04:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
> 
> Scenario:
> - iwlwifi configured in monitor mode - up
> - suspend my laptop
> - crash

[...]


> [42287.379104] iwlwifi :04:00.0: Start IWL Error Log Dump:
> [42287.379107] iwlwifi :04:00.0: Status: 0x, count: 6
> [42287.379109] iwlwifi :04:00.0: Loaded firmware version: 21.302800.0
> [42287.379112] iwlwifi :04:00.0: 0x2B00 | ADVANCED_SYSASSERT

Interesting that you found a good way to reproduce this.  Does it happen
everytime you suspend while monitor mode is enabled?

We have seen a similar case here:

https://bugzilla.kernel.org/show_bug.cgi?id=192691

To use monitor mode you need to use amsdu_size=3 in iwlwifi module
parameters.  Check my comment #15 there.

Can you try this and add your results in that bug report so we can track
the progress?


--
Cheers,
Luca.