summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2016-07-06cfg80211: Add mesh peer AID setting APIMasashi Honma1-0/+1
Previously, mesh power management functionality works only with kernel MPM. Because user space MPM did not report mesh peer AID to kernel, the kernel could not identify the bit in TIM element. So this patch adds mesh peer AID setting API. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-07-06mac80211: parse wide bandwidth channel switch IE with workaroundJohannes Berg1-28/+17
Continuing the workaround implemented in commit 23665aaf9170 ("mac80211: Interoperability workaround for 80+80 and 160 MHz channels") use the same code to parse the Wide Bandwidth Channel Switch element by converting to VHT Operation element since the spec also just refers to that for parsing semantics, particularly with the workaround. While at it, remove some dead code - the IEEE80211_STA_DISABLE_40MHZ flag can never be set at this point since it's checked earlier and the wide_bw_chansw_ie pointer is set to NULL if it's set. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-07-06mac80211: report failure to start (partial) scan as scan abortJohannes Berg1-2/+3
Rather than reporting the scan as having completed, report it as being aborted. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-07-06mac80211: Add support for beacon report radio measurementAvraham Stern2-8/+35
Add the following to support beacon report radio measurement with the measurement mode field set to passive or active: 1. Propagate the required scan duration to the device 2. Report the scan start time (in terms of TSF) 3. Report each BSS's detection time (also in terms of TSF) TSF times refer to the BSS that the interface that requested the scan is connected to. Signed-off-by: Assaf Krauss <assaf.krauss@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com> [changed ath9k/10k, at76c59x-usb, iwlegacy, wl1251 and wlcore to match the new API] Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-07-06nl80211: support beacon report scanningAvraham Stern1-2/+7
Beacon report radio measurement requires reporting observed BSSs on the channels specified in the beacon request. If the measurement mode is set to passive or active, it requires actually performing a scan (passive or active, accordingly), and reporting the time that the scan was started and the time each beacon/probe was received (both in terms of TSF of the BSS of the requesting AP). If the request mode is table, this information is optional. In addition, the radio measurement request specifies the channel dwell time for the measurement. In order to use scan for beacon report when the mode is active or passive, add a parameter to scan request that specifies the channel dwell time, and add scan start time and beacon received time to scan results information. Supporting beacon report is required for Multi Band Operation (MBO). Signed-off-by: Assaf Krauss <assaf.krauss@intel.com> Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-07-06mac80211: agg-rx: refuse ADDBA Request with timeout updateJohannes Berg1-0/+18
The current implementation of handling ADDBA Request while a session is already active with the peer is wrong - in case the peer is using the existing session's dialog token this should be treated as update to the session, which can update the timeout value. We don't really have a good way of supporting that, so reject, but implement the required behaviour in the spec of "Even if the updated ADDBA Request frame is not accepted, the original Block ACK setup remains active." (802.11-2012 10.5.4) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-06-30mac80211: fix fq lockdep warningsMichal Kazior1-0/+4
Some lockdep assertions were not fulfilled and resulted in a kernel warning/call trace if driver used intermediate software queues (e.g. ath10k). Existing code sequences should've guaranteed safety but it's always good to be extra careful. The call trace could look like this: [ 237.335805] ------------[ cut here ]------------ [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211] [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G W E 4.7.0-rc4-wt-ath+ #1377 [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 237.335918] 00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075 [ 237.335928] c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016 [ 237.335938] eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000 [ 237.335948] Call Trace: [ 237.335953] [<c14151e2>] dump_stack+0x76/0xb4 [ 237.335957] [<c1081075>] __warn+0xe5/0x100 [ 237.336002] [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211] [ 237.336046] [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211] [ 237.336053] [<c10810ba>] warn_slowpath_null+0x2a/0x30 [ 237.336095] [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211] [ 237.336137] [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211] [ 237.336180] [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211] [ 237.336222] [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211] [ 237.336258] [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211] [ 237.336275] [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core] [ 237.336292] [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core] [ 237.336301] [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci] [ 237.336307] [<c1470388>] pci_device_remove+0x38/0xb0 ... Fixes: 5caa328e3811 ("mac80211: implement codel on fair queuing flows") Fixes: fa962b92120b ("mac80211: implement fair queueing per txq") Tested-by: Kalle Valo <kvalo@qca.qualcomm.com> Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2016-06-30mac80211: use common cleanup for user/!user_mpmBob Copeland2-23/+13
We've accumulated a couple of different fixes now to mesh_sta_cleanup() due to the different paths that user_mpm and !user_mpm cases take -- one fix to flush nexthop paths and one to fix the counting. The only caller of mesh_plink_deactivate() is mesh_sta_cleanup(), so we can push the user_mpm checks down into there in order to share more code. In doing so, we can remove an extra call to mesh_path_flush_by_nexthop() and the (unnecessary) call to mesh_accept_plinks_update(). This will also ensure the powersaving state code gets called in the user_mpm case. The only cleanup tasks we need to avoid when MPM is in user-space are sending the peering frames and stopping the plink timer, so wrap those in the appropriate check. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2016-06-30mac80211: Encrypt "Group addressed privacy" action framesMasashi Honma2-2/+11
Previously, the action frames to group address was not encrypted. But [1] "Table 8-38 Category values" indicates "Mesh" and "Multihop" category action frames should be encrypted (Group addressed privacy == yes). And the encyption key should be MGTK ([1] 10.13 Group addressed robust management frame procedures). So this patch modifies the code to make it suitable for spec. [1] IEEE Std 802.11-2012 Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2016-06-30mac80211: silence an uninitialized variable warningDan Carpenter1-0/+1
We normally return an uninitialized value, but no one checks it so it doesn't matter. Anyway, let's silence the static checker warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2016-06-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-2/+5
Several cases of overlapping changes, except the packet scheduler conflicts which deal with the addition of the free list parameter to qdisc_enqueue(). Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-28mac80211: Fix mesh estab_plinks counting in STA removal caseJouni Malinen1-2/+5
If a user space program (e.g., wpa_supplicant) deletes a STA entry that is currently in NL80211_PLINK_ESTAB state, the number of established plinks counter was not decremented and this could result in rejecting new plink establishment before really hitting the real maximum plink limit. For !user_mpm case, this decrementation is handled by mesh_plink_deactive(). Fix this by decrementing estab_plinks on STA deletion (mesh_sta_cleanup() gets called from there) so that the counter has a correct value and the Beacon frame advertisement in Mesh Configuration element shows the proper value for capability to accept additional peers. Cc: stable@vger.kernel.org Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
2016-06-10Merge tag 'mac80211-next-for-davem-2016-06-09' of ↵David S. Miller10-95/+573
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== For the next cycle, we have the following: * the biggest change is Michał's work on integrating FQ/codel with the mac80211 internal software queues * cfg80211 connect result gets clarified for the "no connection at all" case * advertisement of per-interface type capabilities, in case they differ (which makes a lot of sense for some capabilities) * most of the nl80211 & hwsim unprivileged namespace operation changes * human-readable VHT capabilities in debugfs * some other cleanups, like spelling ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-09mac80211: implement codel on fair queuing flowsMichal Kazior2-1/+113
There is no other limit other than a global packet count limit when using software queuing. This means a single flow queue can grow insanely long. This is particularly bad for TCP congestion algorithms which requires a little more sophisticated frame dropping scheme than a mere headdrop on limit overflow. Hence apply (a slighly modified, to fit the knobs) CoDel5 on flow queues. This improves TCP convergence and stability when combined with wireless driver which keeps its own tx queue/fifo at a minimum fill level for given link conditions. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-06-09mac80211: add debug knobs for fair queuingMichal Kazior1-0/+173
This adds a debugfs entry to read and modify some fq parameters. This makes it easy to debug, test and experiment. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [remove module parameter for now] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-06-09mac80211: implement fair queueing per txqMichal Kazior8-64/+162
mac80211's software queues were designed to work very closely with device tx queues. They are required to make use of 802.11 packet aggregation easily and efficiently. Due to the way 802.11 aggregation is designed it only makes sense to keep fair queuing as close to hardware as possible to reduce induced latency and inertia and provide the best flow responsiveness. This change doesn't translate directly to immediate and significant gains. End result depends on driver's induced latency. Best results can be achieved if driver keeps its own tx queue/fifo fill level to a minimum. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-06-09mac80211: skip netdev queue control with software queuingMichal Kazior6-45/+66
Qdiscs are designed with no regard to 802.11 aggregation requirements and hand out packet-by-packet with no guarantee they are destined to the same tid. This does more bad than good no matter how fairly a given qdisc may behave on an ethernet interface. Software queuing used per-AC netdev subqueue congestion control whenever a global AC limit was hit. This meant in practice a single station or tid queue could starve others rather easily. This could resonate with qdiscs in a bad way or could just end up with poor aggregation performance. Increasing the AC limit would increase induced latency which is also bad. Disabling qdiscs by default and performing taildrop instead of netdev subqueue congestion control on the other hand makes it possible for tid queues to fill up "in the meantime" while preventing stations starving each other. This increases aggregation opportunities and should allow software queuing based drivers achieve better performance by utilizing airtime more efficiently with big aggregates. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-31mac80211: add vht cap decode to debugfsBen Greear1-2/+76
This makes it a lot easier to understand the capabilities used by the station: VHT supported cap: 0x300819b2 MAX-MPDU-11454 80Mhz RXLDPC SHORT-GI-80 TXSTBC RXSTBC_1 SU-BEAMFORMER-CAPABLE SU-BEAMFORMEE-CAPABLE BEAMFORMEE-STS: 0x0 SOUNDING-DIMENSIONS: 0x0 MU-BEAMFORMER-CAPABLE MPDU-LENGTH-EXPONENT: 0x0 LINK-ADAPTATION-VHT-MRQ-MFB: 0x0 RX-ANTENNA-PATTERN TX-ANTENNA-PATTERN RX MCS: fffe TX MCS: fffe Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-31mac80211: fix fast_tx header alignmentFelix Fietkau1-1/+1
The header field is defined as u8[] but also accessed as struct ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary unaligned accesses, which can be very harmful for performance on many platforms. Fixes: e495c24731a2 ("mac80211: extend fast-xmit for more ciphers") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-31mac80211: mesh: flush mesh paths unconditionallyBob Copeland1-0/+4
Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flush_by_nexthop However, there are a couple of problems here: 1) the paths aren't flushed at all if the MPM is running in userspace (e.g. when using wpa_supplicant or authsae) 2) there is no synchronize_rcu between removing the path and readers accessing the nexthop, which means the following race is possible: CPU0 CPU1 ~~~~ ~~~~ sta_info_destroy_part1() synchronize_net() rcu_read_lock() mesh_nexthop_resolve() mpath = mesh_path_lookup() [...] -> mesh_path_flush_by_nexthop() sta = rcu_dereference( mpath->next_hop) kfree(sta) access sta <-- CRASH Fix both of these by unconditionally flushing paths before destroying the sta, and by adding a synchronize_net() after path flush to ensure no active readers can still dereference the sta. Fixes this crash: [ 348.529295] BUG: unable to handle kernel paging request at 00020040 [ 348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] *pde = 00000000 [ 348.530014] Oops: 0000 [#1] PREEMPT [ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ] [ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1 [ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000 [ 348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0 [ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008 [ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40 [ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690 [ 348.530014] Stack: [ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0 [ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320 [ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1 [ 348.530014] Call Trace: [ 348.530014] [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211] [ 348.530014] [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211] [ 348.530014] [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211] [ 348.530014] [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211] [ 348.530014] [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3 [ 348.530014] [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b [ 348.530014] [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4] [ 348.530014] [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat] [ 348.530014] [<c04c6f45>] ? netif_skb_features+0x14d/0x30a [ 348.530014] [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv] [ 348.530014] [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv] [ 348.530014] [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv] [ 348.530014] [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv] [ 348.530014] [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv] [ 348.530014] [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb] [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge] [ 348.530014] [<f843a35f>] br_forward_finish+0x29/0x74 [bridge] [ 348.530014] [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge] [ 348.530014] [<f843a714>] __br_forward+0x89/0xe7 [bridge] [ 348.530014] [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge] [ 348.530014] [<f843a234>] deliver_clone+0x34/0x3b [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843a66d>] br_flood+0x77/0x95 [bridge] [ 348.530014] [<f843a809>] br_flood_forward+0x13/0x1a [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge] [ 348.530014] [<c04e9b2b>] ? nf_iterate+0x2b/0x6b [ 348.530014] [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge] [ 348.530014] [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge] [ 348.530014] [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b [ 348.530014] [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge] [ 348.530014] [<c023cea4>] ? resched_curr+0x19/0x37 [ 348.530014] [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe [ 348.530014] [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc [ 348.530014] [<c04c4fc1>] __netif_receive_skb+0x47/0x55 [ 348.530014] [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a [ 348.530014] [<c04c61ef>] napi_gro_receive+0x3a/0x94 [ 348.530014] [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb] [ 348.530014] [<c0242bd8>] ? swake_up_locked+0x14/0x26 [ 348.530014] [<c04c5d29>] net_rx_action+0xde/0x250 [ 348.530014] [<c022a743>] __do_softirq+0x8a/0x163 [ 348.530014] [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19 [ 348.530014] [<c021100f>] do_softirq_own_stack+0x26/0x2c [ 348.530014] <IRQ> [ 348.530014] [<c022a957>] irq_exit+0x31/0x6f [ 348.530014] [<c0210eb2>] do_IRQ+0x8d/0xa0 [ 348.530014] [<c058152c>] common_interrupt+0x2c/0x40 [ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005 [ 348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40 [ 348.530014] CR2: 0000000000020040 [ 348.530014] ---[ end trace 48556ac26779732e ]--- [ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt [ 348.530014] Kernel Offset: disabled Cc: stable@vger.kernel.org Reported-by: Fred Veldini <fred.veldini@gmail.com> Tested-by: Fred Veldini <fred.veldini@gmail.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-12Merge tag 'mac80211-next-for-davem-2016-05-12' of ↵David S. Miller3-30/+61
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Some more work for 4.7, notably: * completion and fixups of nla_put_64_64bit() work * remove a/b/g/n from wext nickname to avoid confusion with 11ac (which wouldn't even fit fully there due to string length restrictions) along with some other minor changes/cleanups. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12mac80211: allow software PS-Poll/U-APSD with AP_LINK_PSJohannes Berg1-26/+44
When using RSS, frames might not be processed in the correct order, and thus AP_LINK_PS must be used; most likely with firmware keeping track of the powersave state, this is the case in iwlwifi now. In this case, the driver can use ieee80211_sta_ps_transition() to still have mac80211 manage powersave buffering. However, for U-APSD and PS-Poll this isn't sufficient. If the device can't manage that entirely on its own, mac80211's code should be used. To allow this, export two functions: ieee80211_sta_uapsd_trigger() and ieee80211_sta_pspoll(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-12mac80211: allow same PN for AMSDU sub-framesSara Sharon1-4/+12
Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV as is to the generated MPDUs, so the same PN appears in multiple packets without being a replay attack. Allow driver to explicitly indicate that a frame is allowed to have the same PN as the previous frame. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-12mac80211: remove disconnected APs from BSS tableDavid Spinadel1-0/+5
In some cases, after a sudden AP disappearing and reconnection to another AP in the same ESS, user space gets the old AP in scan results (cached). User space may decide to roam to that old AP which will cause a disconnection and longer recovery. Remove APs that are probably out of range from BSS table. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-05-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-2/+2
Conflicts: net/ipv4/ip_gre.c Minor conflicts between tunnel bug fixes in net and ipv6 tunnel cleanups in net-next. Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-27mac80211: fix statistics leak if dev_alloc_name() failsJohannes Berg1-2/+2
In the case that dev_alloc_name() fails, e.g. because the name was given by the user and already exists, we need to clean up properly and free the per-CPU statistics. Fix that. Cc: stable@vger.kernel.org Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-12cfg80211: remove enum ieee80211_bandJohannes Berg20-106/+106
This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller8-25/+86
2016-04-06mac80211: fix "warning: ‘target_metric’ may be used uninitialized"Jeff Mahoney1-1/+1
This fixes: net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function target_metric is only consumed when reply = true so no bug exists here, but not all versions of gcc realize it. Initialize to 0 to remove the warning. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rateFelix Fietkau1-0/+54
Prevents excessive A-MSDU aggregation at low data rates or bad conditions. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: add A-MSDU tx supportFelix Fietkau5-0/+166
Requires software tx queueing and fast-xmit support. For good performance, drivers need frag_list support as well. This avoids the need for copying data of aggregated frames. Running without it is only supported for debugging purposes. To avoid performance and packet size issues, the rate control module or driver needs to limit the maximum A-MSDU size by setting max_rc_amsdu_len in struct ieee80211_sta. Signed-off-by: Felix Fietkau <nbd@openwrt.org> [fix locking issue] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: enable collecting station statistics per-CPUJohannes Berg4-46/+138
If the driver advertises the new HW flag USE_RSS, make the station statistics on the fast-rx path per-CPU. This will enable calling the RX in parallel, only hitting locking or shared cachelines when the fast-RX path isn't available. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: add fast-rx pathJohannes Berg7-3/+409
The regular RX path has a lot of code, but with a few assumptions on the hardware it's possible to reduce the amount of code significantly. Currently the assumptions on the driver are the following: * hardware/driver reordering buffer (if supporting aggregation) * hardware/driver decryption & PN checking (if using encryption) * hardware/driver did de-duplication * hardware/driver did A-MSDU deaggregation * AP_LINK_PS is used (in AP mode) * no client powersave handling in mac80211 (in client mode) of which some are actually checked per packet: * de-duplication * PN checking * decryption and additionally packets must * not be A-MSDU (have been deaggregated by driver/device) * be data packets * not be fragmented * be unicast * have RFC 1042 header Additionally dynamically we assume: * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed * station must be authorized * 4-addr format not enabled Some data needed for the RX path is cached in a new per-station "fast_rx" structure, so that we only need to look at this and the packet, no other memory when processing packets on the fast RX path. After doing the above per-packet checks, the data path collapses down to a pretty simple conversion function taking advantage of the data cached in the small fast_rx struct. This should speed up the RX processing, and will make it easier to reason about parallelizing RX (for which statistics will need to be per-CPU still.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: fix RX u64 stats consistency on 32-bit platformsJohannes Berg3-29/+54
On 32-bit platforms, the 64-bit counters we keep need to be protected to be consistently read. Use the u64_stats_sync mechanism to do that. In order to not end up with overly long lines, refactor the tidstats assignments a bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: fix last RX rate data consistencyJohannes Berg3-49/+77
When storing the last_rate_* values in the RX code, there's nothing to guarantee consistency, so a concurrent reader could see, e.g. last_rate_idx on the new value, but last_rate_flag still on the old, getting completely bogus values in the end. To fix this, I lifted the sta_stats_encode_rate() function from my old rate statistics code, which encodes the entire rate data into a single 16-bit value, avoiding the consistency issue. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: add separate last_ack variableJohannes Berg4-9/+24
Instead of touching the rx_stats.last_rx from the status path, introduce and use a status_stats.last_ack variable. This will make rx_stats.last_rx indicate when the last frame was received, making it available for real "last_rx" and statistics gathering; statistics, when done per-CPU, will need to figure out which place was updated last for those items where the "last" value is exposed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: remove rx_stats.last_rx update after sta allocJohannes Berg2-6/+0
There's no need to update rx_stats.last_rx after allocating a station since it's already updated during allocation. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: move averaged values out of rx_statsJohannes Berg4-10/+12
Move the averaged values out of rx_stats and into rx_stats_avg, to cleanly split them out. The averaged ones cannot be supported for parallel RX in a per-CPU fashion, while the other values can be collected per CPU and then combined/selected when needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: move semicolon out of CALL_RXH macroJohannes Berg1-17/+17
Move the semicolon, people typically assume that and once line already put a semicolon behind the "call". Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: count MSDUs in A-MSDU properlyJohannes Berg1-9/+9
For the RX MSDU statistics, we need to count the number of MSDUs created and accepted from an A-MSDU. Right now, all frames in any A-MSDUs were completely ignored. Fix this by moving the RX MSDU statistics accounting into the deliver function. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-06mac80211: allow passing transmitter station on RXJohannes Berg1-5/+13
Sometimes drivers already looked up, or know out-of-band from their device, which station transmitted a given RX frame. Allow them to pass the station pointer to mac80211 to save the extra lookup. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: flush paths outside of plink lockBob Copeland1-2/+9
Lockdep warned of a lock dependency between the mesh_plink lock and the internal lock for the rhashtable. The problem is that the rhashtable code uses a spin lock with softirqs enabled, while mesh_plink_timer executes a walk (to flush paths on a state change) inside a softirq with the plink lock held. This leads to the following deadlock if the timer fires while rht lock is held on this CPU, and plink lock is held on another CPU: CPU0 CPU1 ---- ---- lock(&(&ht->lock)->rlock); local_irq_disable(); lock(&(&sta->mesh->plink_lock)->rlock); lock(&(&ht->lock)->rlock); <Interrupt> lock(&(&sta->mesh->plink_lock)->rlock); *** DEADLOCK *** Fix by waiting until we drop the plink lock to flush paths. Fixes: d48a1b7cd439 ("mac80211: mesh: convert path table to rhashtable") Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: fix cleanup for mesh pathtableBob Copeland3-2/+8
The mesh path table needs to be around for the entire time the interface is in mesh mode, as users can perform an mpath dump at any time. The existing path table lifetime is instead tied to the mesh BSS which can cause crashes when different MBSSes are joined in the context of a single interface, or when the path table is dumped when no MBSS is joined. Introduce a new function to perform the final teardown of the interface and perform path table cleanup there. We already free the individual path elements when the leaving the mesh so no additional cleanup is needed there. This fixes the following crash: [ 47.753026] BUG: unable to handle kernel paging request at fffffff0 [ 47.753026] IP: [<c0239765>] kthread_data+0xa/0xe [ 47.753026] *pde = 00741067 *pte = 00000000 [ 47.753026] Oops: 0000 [#4] PREEMPT [ 47.753026] Modules linked in: ppp_generic slhc 8021q garp mrp sch_fq_codel iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ath9k_htc ath5k 8139too ath10k_pci ath10k_core arc4 ath9k ath9k_common ath9k_hw mac80211 ath cfg80211 cpufreq_powersave br_netfilter bridge stp llc ipw usb_wwan sierra_net usbnet af_alg natsemi via_rhine mii iTCO_wdt iTCO_vendor_support gpio_ich sierra coretemp pcspkr i2c_i801 lpc_ich ata_generic ata_piix libata ide_pci_generic piix e1000e igb i2c_algo_bit ptp pps_core [last unloaded: 8139too] [ 47.753026] CPU: 0 PID: 12 Comm: kworker/u2:1 Tainted: G D W 4.5.0-wt-V3 #6 [ 47.753026] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 47.753026] task: f645a0c0 ti: f6462000 task.ti: f6462000 [ 47.753026] EIP: 0060:[<c0239765>] EFLAGS: 00010002 CPU: 0 [ 47.753026] EIP is at kthread_data+0xa/0xe [ 47.753026] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 [ 47.753026] ESI: f645a0c0 EDI: f645a2fc EBP: f6463a80 ESP: f6463a78 [ 47.753026] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 47.753026] CR0: 8005003b CR2: 00000014 CR3: 353e5000 CR4: 00000690 [ 47.753026] Stack: [ 47.753026] c0236866 00000000 f6463aac c05768b4 00000009 f6463ba8 f6463ab0 c0247010 [ 47.753026] 00000000 f645a0c0 f6464000 00000009 f6463ba8 f6463ab8 c0576eb2 f645a0c0 [ 47.753026] f6463aec c0228be4 c06335a4 f6463adc f6463ad0 c06c06d4 f6463ae4 c02471b0 [ 47.753026] Call Trace: [ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [<c05768b4>] __schedule+0xda/0x587 [ 47.753026] [<c0247010>] ? vprintk_default+0x12/0x14 [ 47.753026] [<c0576eb2>] schedule+0x72/0x89 [ 47.753026] [<c0228be4>] do_exit+0xb8/0x71d [ 47.753026] [<c02471b0>] ? kmsg_dump+0xa9/0xae [ 47.753026] [<c0203576>] oops_end+0x69/0x70 [ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5 [ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd [ 47.753026] [<c05798f8>] error_code+0x58/0x60 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c0239765>] ? kthread_data+0xa/0xe [ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [<c05768b4>] __schedule+0xda/0x587 [ 47.753026] [<c0247010>] ? vprintk_default+0x12/0x14 [ 47.753026] [<c0576eb2>] schedule+0x72/0x89 [ 47.753026] [<c0228be4>] do_exit+0xb8/0x71d [ 47.753026] [<c02471b0>] ? kmsg_dump+0xa9/0xae [ 47.753026] [<c0203576>] oops_end+0x69/0x70 [ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5 [ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd [ 47.753026] [<c05798f8>] error_code+0x58/0x60 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c0239765>] ? kthread_data+0xa/0xe [ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78 [ 47.753026] [<c05768b4>] __schedule+0xda/0x587 [ 47.753026] [<c0391e32>] ? put_io_context_active+0x6d/0x95 [ 47.753026] [<c0576eb2>] schedule+0x72/0x89 [ 47.753026] [<c02291f8>] do_exit+0x6cc/0x71d [ 47.753026] [<c0203576>] oops_end+0x69/0x70 [ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5 [ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10 [ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320 [ 47.753026] [<c03b9160>] ? debug_smp_processor_id+0x12/0x16 [ 47.753026] [<c02015e2>] ? __switch_to+0x24/0x40e [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd [ 47.753026] [<c05798f8>] error_code+0x58/0x60 [ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a [ 47.753026] [<c03b59d2>] ? rhashtable_walk_init+0x5c/0x93 [ 47.753026] [<f9843221>] mesh_path_tbl_expire.isra.24+0x19/0x82 [mac80211] [ 47.753026] [<f984408b>] mesh_path_expire+0x11/0x1f [mac80211] [ 47.753026] [<f9842bb7>] ieee80211_mesh_work+0x73/0x1a9 [mac80211] [ 47.753026] [<f98207d1>] ieee80211_iface_work+0x2ff/0x311 [mac80211] [ 47.753026] [<c0235fa3>] process_one_work+0x14b/0x24e [ 47.753026] [<c0236313>] worker_thread+0x249/0x343 [ 47.753026] [<c02360ca>] ? process_scheduled_works+0x24/0x24 [ 47.753026] [<c0239359>] kthread+0x9e/0xa3 [ 47.753026] [<c0578e50>] ret_from_kernel_thread+0x20/0x40 [ 47.753026] [<c02392bb>] ? kthread_parkme+0x18/0x18 [ 47.753026] Code: 6b c0 85 c0 75 05 e8 fb 74 fc ff 89 f8 84 c0 75 08 8d 45 e8 e8 34 dd 33 00 83 c4 28 5b 5e 5f 5d c3 55 8b 80 10 02 00 00 89 e5 5d <8b> 40 f0 c3 55 b9 04 00 00 00 89 e5 52 8b 90 10 02 00 00 8d 45 [ 47.753026] EIP: [<c0239765>] kthread_data+0xa/0xe SS:ESP 0068:f6463a78 [ 47.753026] CR2: 00000000fffffff0 [ 47.753026] ---[ end trace 867ca0bdd0767790 ]--- Fixes: 3b302ada7f0a ("mac80211: mesh: move path tables into if_mesh") Reported-by: Fred Veldini <fred.veldini@gmail.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: fix mesh path kerneldocBob Copeland1-8/+12
Several of the mesh path fields are undocumented and some of the documentation is no longer correct or relevant after the switch to rhashtable. Clean up the kernel doc accordingly and reorder some fields to match the structure layout. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: reorder structure membersBob Copeland1-3/+2
Reduce padding waste in struct mesh_table and struct rmc_entry by moving the smaller fields to the end. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: embed gates hlist head directlyBob Copeland2-15/+5
Since we have converted the mesh path tables to rhashtable, we are no longer swapping out the entire mesh_pathtbl pointer with RCU. As a result, we no longer need indirection to the hlist head for the gates list and can simply embed it, saving a pair of pointer-sized allocations. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: use hlist for rmc cacheBob Copeland2-10/+12
The RMC cache has 256 list heads plus a u32, which puts it at the unfortunate size of 4104 bytes with padding. kmalloc() will then round this up to the next power-of-two, so we wind up actually using two pages here where most of the second is wasted. Switch to hlist heads here to reduce the structure size down to fit within a page. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: handle failed alloc for rmc cacheBob Copeland1-0/+3
In the unlikely case that mesh_rmc_init() fails with -ENOMEM, the rmc pointer will be left as NULL but the interface is still operational because ieee80211_mesh_init_sdata() is not allowed to fail. If this happens, we would blindly dereference rmc when checking whether a multicast frame is in the cache. Instead just drop the frames in the forwarding path. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: mesh: fix crash in mesh_path_timerBob Copeland3-15/+25
The mesh_path_reclaim() function, called from an rcu callback, cancels the mesh_path_timer associated with a mesh path. Unfortunately, this call can happen much later, perhaps after the hash table itself is destroyed. Such a situation led to the following crash in mesh_path_send_to_gates() when dereferencing the tbl pointer: [ 23.901661] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 23.905516] IP: [<ffffffff814c910b>] mesh_path_send_to_gates+0x2b/0x740 [ 23.908757] PGD 99ca067 PUD 99c4067 PMD 0 [ 23.910789] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 23.913485] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-wt+ #43 [ 23.916675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 23.920471] task: ffffffff81685500 ti: ffffffff81678000 task.ti: ffffffff81678000 [ 23.922619] RIP: 0010:[<ffffffff814c910b>] [<ffffffff814c910b>] mesh_path_send_to_gates+0x2b/0x740 [ 23.925237] RSP: 0018:ffff88000b403d30 EFLAGS: 00010286 [ 23.926739] RAX: 0000000000000000 RBX: ffff880009bc0d20 RCX: 0000000000000102 [ 23.928796] RDX: 000000000000002e RSI: 0000000000000001 RDI: ffff880009bc0d20 [ 23.930895] RBP: ffff88000b403e18 R08: 0000000000000001 R09: 0000000000000001 [ 23.932917] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880009c20940 [ 23.936370] R13: ffff880009bc0e70 R14: ffff880009c21c40 R15: ffff880009bc0d20 [ 23.939823] FS: 0000000000000000(0000) GS:ffff88000b400000(0000) knlGS:0000000000000000 [ 23.943688] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 23.946429] CR2: 0000000000000008 CR3: 00000000099c5000 CR4: 00000000000006b0 [ 23.949861] Stack: [ 23.950840] 000000000000002e ffff880009c20940 ffff88000b403da8 ffffffff8109e551 [ 23.954467] ffffffff82711be2 000000000000002e 0000000000000000 ffffffff8166a5f5 [ 23.958141] 0000000000685ce8 0000000000000246 ffff880009bc0d20 ffff880009c20940 [ 23.961801] Call Trace: [ 23.962987] <IRQ> [ 23.963963] [<ffffffff8109e551>] ? vprintk_emit+0x351/0x5e0 [ 23.966782] [<ffffffff8109e8ff>] ? vprintk_default+0x1f/0x30 [ 23.969529] [<ffffffff810ffa41>] ? printk+0x48/0x50 [ 23.971956] [<ffffffff814ceef3>] mesh_path_timer+0x133/0x160 [ 23.974707] [<ffffffff814cedc0>] ? mesh_nexthop_resolve+0x230/0x230 [ 23.977775] [<ffffffff810b04ee>] call_timer_fn+0xce/0x330 [ 23.980448] [<ffffffff810b0425>] ? call_timer_fn+0x5/0x330 [ 23.983126] [<ffffffff814cedc0>] ? mesh_nexthop_resolve+0x230/0x230 [ 23.986091] [<ffffffff810b097c>] run_timer_softirq+0x22c/0x390 Instead of cancelling in the RCU callback, set a new flag to prevent the timer from being rearmed, and then cancel the timer synchronously when freeing the mesh path. This leaves mesh_path_reclaim() doing nothing but kfree, so switch to kfree_rcu(). Fixes: 3b302ada7f0a ("mac80211: mesh: move path tables into if_mesh") Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-04-05mac80211: track and tell driver about GO client P2P PS abilitiesAyala Beker2-0/+33
Legacy clients don't support P2P power save mechanism, and thus if a P2P GO has a legacy client connected to it, it should disable P2P PS mechanisms. Let the driver know about this with a new bss_conf parameter. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>