I found another crash when deleting lots of virtual stations
in a congested environment.  I think the problem is that
the ieee80211_mlme_notify_scan_completed could call
ieee80211_restart_sta_timer for a stopped interface
that was about to be deleted.

With the following patch I am unable to reproduce the
crash.
Signed-off-by: Ben Greear <greearb@candelatech.com>
[move check, also make the same change in mesh]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If a P2P device wdev is removed while it has a scan, then the
scan completion might crash later as it is already freed by
that time. To avoid the crash always check the scan completion
when the P2P device is being removed for some reason. If the
driver already canceled it, don't want and free it, otherwise
warn and leak it to avoid later crashes.

In order to do this, locking needs to be changed away from the
rdev mutex (which can't always be guaranteed). For now, use
the sched_scan_mtx instead, I'll rename it to just scan_mtx in
a later patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The virtual monitor interface has a locking issue, it calls
into the channel context code with the iflist mutex held
which isn't allowed since it is usually acquired the other
way around. The mutex is still required for the interface
iteration, but need not be held across the channel calls.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Arend reported a crash in tracing if the driver returns an
ERR_PTR() value from the add_virtual_intf() callback. This
is due to the tracing then still attempting to dereference
the "pointer", fix this by using IS_ERR_OR_NULL().
Reported-by: Arend van Spriel <arend@broadcom.com>
Tested-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If a P2P Device interface receives an unhandled action
frame, we attempt to return it. This crashes because it
doesn't have a channel context. Fix the crash by using
status->band and properly mark the return frame as an
off-channel frame.
Reported-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In the odd case that while updating information from a beacon,
a BSS was found that is part of a hidden group, we drop the
new information. In this case, however, we leak the IE buffer
from the update, and erroneously update the entry's timestamp
so it will never time out. Fix both these issues.

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There is NETDEV_ENTRY that was incorrectly assigned as WIPHY_ASSIGN,
fix it.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If there are keys left during station removal, then a
synchronize_net() will be done (for each key, I have a
patch to address this for 3.10), otherwise it won't be
done at all which causes issues because the station
could be used for TX while it's being removed from the
driver -- that might confuse the driver.

Fix this by always doing synchronize_net() if no key
was present any more.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When setting a monitor interface up or down, the idle state needs to be
recalculated, otherwise the hardware will just stay in its previous idle
state.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The VHT MCSes we advertise to the AP were supposed to
be restricted to the AP, but due to a bug in the logic
mac80211 will advertise rates to the AP that aren't
even supported by the local device. To fix this skip
any adjustment if the NSS isn't supported at all.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Introduced with de74a1d9
"mac80211: fix WPA with VLAN on AP side with ps-sta".
Apparently overwrites the sdata pointer with non-valid data in
the case of mesh.
Fix this by checking for IFTYPE_AP_VLAN.
Signed-off-by: Marco Porsch <marco@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Given a device with many channels capabilities the wiphy
information can still overflow even though its size in
3.9 was reduced to 3.8 levels. For new userspace and
kernel 3.10 we're going to implement a new "split dump"
protocol that can use multiple messages per wiphy.

For now though, add a workaround to be able to send more
information to userspace. Since generic netlink doesn't
have a way to set the minimum dump size globally, and we
wouldn't really want to set it globally anyway, increase
the size only when needed, as described in the comments.
As userspace might not be prepared for large buffers, we
can only use 4k.

Also increase the size for the get_wiphy command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

After Felix's patch it was still broken in case you
used more than just a single monitor interface. Fix
it better now.
Reported-by: Sujith Manoharan <sujith@msujith.org>
Tested-by: Sujith Manoharan <sujith@msujith.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This is another case of data increasing the size of the
wiphy information significantly with a new feature, for
now remove this as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Some mlme work structs are not cancelled on disassociation
nor interface deletion, which leads to them running after
the memory has been freed

There is not a clean way to cancel these in the disassociation
logic because they must be canceled outside of the ifmgd->mtx
lock, so just cancel them in mgd_stop logic that tears down
the station.

This fixes the crashes we see in 3.7.9+.  The crash stack
trace itself isn't so helpful, but this warning gives
more useful info:

WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211]
Modules linked in: [...]
Pid: 14743, comm: iw Tainted: G         C O 3.7.9+ #11
Call Trace:
 [<ffffffff81087ef8>] warn_slowpath_common+0x80/0x98
 [<ffffffff81087fa4>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff812a2608>] debug_print_object+0x7c/0x8d
 [<ffffffff812a2bca>] debug_check_no_obj_freed+0x95/0x1c3
 [<ffffffff8114cc69>] slab_free_hook+0x70/0x79
 [<ffffffff8114ea3e>] kfree+0x62/0xb7
 [<ffffffff8149f465>] netdev_release+0x39/0x3e
 [<ffffffff8136ad67>] device_release+0x52/0x8a
 [<ffffffff812937db>] kobject_release+0x121/0x158
 [<ffffffff81293612>] kobject_put+0x4c/0x50
 [<ffffffff8148f0d7>] netdev_run_todo+0x25c/0x27e

Cc: stable@vger.kernel.org
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Re-order the quiesce code so that timers are always
stopped before work-items are flushed. This was not
the problem I saw, but I think it may still be more
correct.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When not using channel contexts with only monitor mode interfaces being
active, report local->monitor_chandef to userspace.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When the driver does not want a monitor mode VIF, no channel context is
allocated for it. This causes ieee80211_recalc_idle to put the hardware
into idle mode if only a monitor mode is active, breaking injection.

Fix this by checking local->monitors in addition to active channel
contexts.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Commit 6c17b77b (mac80211: Fix tx queue
handling during scans) contains a bug that causes off-channel frames to
get queued when they should be handed down to the driver for transmit.
Prevent this from happening.
Reported-by: Fabio Rossi <rossi.f@inwind.it>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Unicast frame with unknown forwarding information always trigger
the path discovery assuming destination is always located inside the
MBSS. This patch allows the forwarding to look for mesh gate if path
discovery inside the MBSS has failed.
Reported-by: Cedric Voncken <cedric.voncken@acksys.fr>
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Just like the radar information, the TCP WoWLAN capability
data can increase the wiphy information and make it too
big. Remove the TCP WoWLAN information; no driver supports
it and new userspace tools will be required as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The wiphy information is getting very close to being too
much for a typical netlink dump message and adding the
radar attributes to channels and interface combinations
can push it over the limit, which means userspace gets no
information whatsoever. Therefore, remove these again for
now, no driver actually supports radar detection anyway
and a modified userspace is required as well.

We're working on a solution that will allow userspace to
request splitting the information across multiple netlink
messages, which will allow us to add this back.

Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The ieee80211_beacon_add_tim() function might be called
by drivers with BHs enabled, which causes a potential
deadlock if TX happens at the same time and attempts to
lock the tim_lock as well. Use spin_lock_bh to fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add the missing unlock before return from function brcmf_notify_vif_event()
in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Unload sequence for mwifiex PCIE driver is as follows:
1. Invoking cleanup module from kernel results into
   pci_unregister_driver
2. Kernel invokes PCIE remove() handler which disconnects all
   interfaces.
3. One step during disconnect is to clean PCIE TX rings.
   During this we read txbd_rdptr from FW.

While loading driver next time, we see pci_enable_device()
results into system freeze. This may have happened because we
accessed PCI device after unregistering from bus driver.
Removing this ioread() operation resolves this bug.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If the system suspends with mwifiex wifi powered on, and is then woken
by an ICMP ping packet, the ping response is discarded by the kernel
because the kernel incorrectly thinks there is no carrier.

I can't see any valid reason to want to report loss of carrier here,
so remove the offending code.

Fixes http://dev.laptop.org/ticket/12554Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When memory allocation using, kmalloc() fails, report appropriate error value.
Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch fixes an instance of DMA buffer on stack(being passed to
usb_control_msg) for the wireless USB version of the Agere Orinoco card driver.
It also fixes the missing audit for the return value of firmware download
routine. Found using smatch.
Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;
	};

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

[v2]:
 - Use WARN_ON_ONCE instead of WARN_ON

Cc: <stable@vger.kernel.org>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

For STA mode, collect VHT realated IEs from the Beacons or Probe
Responses and append similar VHT related IEs to association
requests.

For AP mode, get VHT related capability information and share it
with cfg80211 at the time of wiphy register. This information is
further used by cfg80211 and hostapd to start an AP with 802.11AC
support.

Currently only 8897 supports 802.11AC.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

They all can make one line.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

While unloading driver, we free all pending TX packets by flushing
TX ring. There is unhandled case for PCIE8897 while checking for
ring empty condition.

This patch adds the handling by calling mwifiex_pcie_txbd_empty().
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

I removed a bit too much info last time.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Theoretically, the card may not enter CTKILL:
In case the timer that iwl_prepare_ct_kill_task is setting,
will expire before tt->state revert to its previous state.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The time event data structures are required also for P2P Device
interface.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The FW can differentiate between scans, according to the interface
type on which the scan was issues. Supply the interfaces type
information to the FW.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Occasionally, we would run into this warning:

  iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
  iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
  iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
  wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
  ------------[ cut here ]------------
  WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
  Modules linked in: [...]
  Call Trace:
   [<c1046e42>] warn_slowpath_common+0x72/0xa0
   [<c1046e92>] warn_slowpath_null+0x22/0x30
   [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
   [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
   [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
   [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]

The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
 * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
 * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
   for that is sync and also uses a notification wait for the
   response (to avoid another race condition)
 * the response for the TE 0x2601 removal comes from the
   firmware, and is handled by the notification wait handler
   that's really waiting for the second response, but can't
   tell the difference, we therefore see the message
   "TIME_EVENT_CMD response - UID = 0x2601" instead of
   "TIME_EVENT_CMD response - UID = 0x2701".

Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.

Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This is helpful for debugging the time event warning,
but also in general to see what's going on.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>