ath10k: remove unnecessary htt rx corruption check

While fixing a bug reported by Avery I went ahead
and added a warning suspecting there might be
something more to the bug. This ended up with
people reporting they see warnings during heavy
traffic. This bought me some time and helped me
understand the problem better - apparently fw/hw
can report a chained msdus as follows: 1 msdu, 1
chained, 1 msdu (0 length).

The patch removes the extra check but leaves the
other change that fixed the original skb_push
panic bug (msdu_chaining was overwritten in an
unfortunate way which made the above example to
be treated as non-chained case).

Reported-by: Yeoh Chun-Yeow <yeohchunyeow@gmail.com>
Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: fix 8th virtual AP interface with DFS

Firmware 10.x supports up to 8 virtual AP interfaces, but in a DFS
channel it was possible to create only 7 interfaces as ath10k internal
creates a monitor interface for DFS. Previous vdev map initialization
was missing enough space for 8 + 1 vdevs due to wrong define used and
that's why there was no space for 8th interface. Use the correct define
TARGET_10X_NUM_VDEVS with 10.x firmware to make it possible to create
the 8th virtual interface.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
perf tools: Fix segfault in cumulative.callchain report

When cumulative callchain mode is on, we could get samples with
with no actual hits. This breaks the assumption of the annotation
code, that each sample has annotation counts allocated and leads
to segfault.

Fixing this by additional checks for annotation stats.

Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1402821332-12419-1-git-send-email-jolsa@kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
perf symbols: Get kernel start address by symbol name

The function machine__get_kernel_start_addr() was taking the first symbol
of kallsyms as the start address. This is incorrect in certain cases
where the first symbol is something at 0, while the actual kernel
functions begin at a later point (e.g. 0x80200000).

This patch fixes machine__get_kernel_start_addr() to search for the
symbol "_text" or "_stext", which marks the beginning of kernel mapping.
This was already being done in machine__create_kernel_maps(). Thus, this
patch is just a refactor, to move that code into
machine__get_kernel_start_addr().

Signed-off-by: Simon Que <sque@chromium.org>
Link: http://lkml.kernel.org/r/1402943529-13244-1-git-send-email-sque@chromium.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Revert "Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012."

This reverts commit ca58e594da2486c1d28e7ad547d82266604ec4ce.

For some unclear reason this patch tries to add suport for the
product ID 0xe005, but it ends up adding product ID 0x3005 to
all the tables. This is obviously wrong and causing multiple
issues.

The original patch seemed to be fine, but what ended up in 3.15
is not what the patch intended. The commit 0a3658cccdf53 is
already present and adds support for this hardware. This means
only revert of this broken commit is requird.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reported-by: Alexander Holler <holler@ahsoftware.de>
Cc: stable@vger.kernel.org # 3.15.x
Bluetooth: Fix overriding higher security level in SMP

When we receive a pairing request or an internal request to start
pairing we shouldn't blindly overwrite the existing pending_sec_level
value as that may actually be higher than the new one. This patch fixes
the SMP code to only overwrite the value in case the new one is higher
than the old.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Refactor authentication method lookup into its own function

We'll need to do authentication method lookups from more than one place,
so refactor the lookup into its own function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fix rejecting pairing in case of insufficient capabilities

If we need an MITM protected connection but the local and remote IO
capabilities cannot provide it we should reject the pairing attempt in
the appropriate way. This patch adds the missing checks for such a
situation to the smp_cmd_pairing_req() and smp_cmd_pairing_rsp()
functions.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fix for ACL disconnect when pairing fails

When pairing fails hci_conn refcnt drops below zero. This cause that
ACL link is not disconnected when disconnect timeout fires.

Probably this is because l2cap_conn_del calls l2cap_chan_del for each
channel, and inside l2cap_chan_del conn is dropped. After that loop
hci_chan_del is called which also drops conn.

Anyway, as it is desrcibed in hci_core.h, it is known that refcnt
drops below 0 sometimes and it should be fine. If so, let disconnect
link when hci_conn_timeout fires and refcnt is 0 or below. This patch
does it.

This affects PTS test SM_TC_JW_BV_05_C

Logs from scenario:

[69713.706227] [6515] pair_device:
[69713.706230] [6515] hci_conn_add: hci0 dst 00:1b:dc:06:06:22
[69713.706233] [6515] hci_dev_hold: hci0 orig refcnt 8
[69713.706235] [6515] hci_conn_init_sysfs: conn ffff88021f65a000
[69713.706239] [6515] hci_req_add_ev: hci0 opcode 0x200d plen 25
[69713.706242] [6515] hci_prepare_cmd: skb len 28
[69713.706243] [6515] hci_req_run: length 1
[69713.706248] [6515] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 0
[69713.706251] [6515] hci_dev_put: hci0 orig refcnt 9
[69713.706281] [8909] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1
[69713.706288] [8909] hci_send_frame: hci0 type 1 len 28
[69713.706290] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 28
[69713.706316] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.706382] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711664] [8909] hci_rx_work: hci0
[69713.711668] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 6
[69713.711680] [8909] hci_rx_work: hci0 Event packet
[69713.711683] [8909] hci_cs_le_create_conn: hci0 status 0x00
[69713.711685] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711688] [8909] hci_req_cmd_complete: opcode 0x200d status 0x00
[69713.711690] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711695] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711744] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818875] [8909] hci_rx_work: hci0
[69713.818889] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 21
[69713.818913] [8909] hci_rx_work: hci0 Event packet
[69713.818917] [8909] hci_le_conn_complete_evt: hci0 status 0x00
[69713.818922] [8909] hci_send_to_control: len 19
[69713.818927] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818938] [8909] hci_conn_add_sysfs: conn ffff88021f65a000
[69713.818975] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69713.818981] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
...
[69713.819021] [8909] hci_dev_hold: hci0 orig refcnt 10
[69713.819025] [8909] l2cap_connect_cfm: hcon ffff88021f65a000 bdaddr 00:1b:dc:06:06:22 status 0
[69713.819028] [8909] hci_chan_create: hci0 hcon ffff88021f65a000
[69713.819031] [8909] l2cap_conn_add: hcon ffff88021f65a000 conn ffff880221005c00 hchan ffff88020d60b1c0
[69713.819034] [8909] l2cap_conn_ready: conn ffff880221005c00
[69713.819036] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.819037] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x02
[69713.819039] [8909] smp_chan_create:
[69713.819041] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 1
[69713.819043] [8909] smp_send_cmd: code 0x01
[69713.819045] [8909] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.819046] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819049] [8909] hci_queue_acl: hci0 nonfrag skb ffff88005157c100 len 15
[69713.819055] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819057] [8909] l2cap_le_conn_ready:
[69713.819064] [8909] l2cap_chan_create: chan ffff88005ede2c00
[69713.819066] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 1
[69713.819069] [8909] l2cap_sock_init: sk ffff88005ede5800
[69713.819072] [8909] bt_accept_enqueue: parent ffff880160356000, sk ffff88005ede5800
[69713.819074] [8909] __l2cap_chan_add: conn ffff880221005c00, psm 0x00, dcid 0x0004
[69713.819076] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 2
[69713.819078] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 2
[69713.819080] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x01
[69713.819082] [8909] l2cap_sock_ready_cb: sk ffff88005ede5800, parent ffff880160356000
[69713.819086] [8909] le_pairing_complete_cb: status 0
[69713.819091] [8909] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.819093] [8909] hci_sched_acl: hci0
[69713.819094] [8909] hci_sched_sco: hci0
[69713.819096] [8909] hci_sched_esco: hci0
[69713.819098] [8909] hci_sched_le: hci0
[69713.819099] [8909] hci_chan_sent: hci0
[69713.819101] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 10
[69713.819104] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff88005157c100 len 15 priority 7
[69713.819106] [8909] hci_send_frame: hci0 type 2 len 15
[69713.819108] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 15
[69713.819119] [8909] hci_chan_sent: hci0
[69713.819121] [8909] hci_prio_recalculate: hci0
[69713.819123] [8909] process_pending_rx:
[69713.819226] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
...
[69713.822022] [6450] l2cap_sock_accept: sk ffff880160356000 timeo 0
[69713.822024] [6450] bt_accept_dequeue: parent ffff880160356000
[69713.822026] [6450] bt_accept_unlink: sk ffff88005ede5800 state 1
[69713.822028] [6450] l2cap_sock_accept: new socket ffff88005ede5800
[69713.822368] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822375] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.822383] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822414] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
...
[69713.823255] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.823259] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.824322] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.824330] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.825029] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.825187] [6450] l2cap_sock_sendmsg: sock ffff8800941ab700, sk ffff88005ede5800
[69713.825189] [6450] bt_sock_wait_ready: sk ffff88005ede5800
[69713.825192] [6450] l2cap_create_basic_pdu: chan ffff88005ede2c00 len 3
[69713.825196] [6450] l2cap_do_send: chan ffff88005ede2c00, skb ffff880160b0b500 len 7 priority 0
[69713.825199] [6450] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.825201] [6450] hci_queue_acl: hci0 nonfrag skb ffff880160b0b500 len 11
[69713.825210] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.825213] [8909] hci_sched_acl: hci0
[69713.825214] [8909] hci_sched_sco: hci0
[69713.825216] [8909] hci_sched_esco: hci0
[69713.825217] [8909] hci_sched_le: hci0
[69713.825219] [8909] hci_chan_sent: hci0
[69713.825221] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 9
[69713.825223] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff880160b0b500 len 11 priority 0
[69713.825225] [8909] hci_send_frame: hci0 type 2 len 11
[69713.825227] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 11
[69713.825242] [8909] hci_chan_sent: hci0
[69713.825253] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825253] [8909] hci_prio_recalculate: hci0
[69713.825292] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825768] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.866902] [8909] hci_rx_work: hci0
[69713.866921] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.866928] [8909] hci_rx_work: hci0 Event packet
[69713.866931] [8909] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.866937] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.866939] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.866940] [8909] hci_sched_acl: hci0
...
[69713.866944] [8909] hci_sched_le: hci0
[69713.866953] [8909] hci_chan_sent: hci0
[69713.866997] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867840] [28074] hci_rx_work: hci0
[69713.867844] [28074] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.867850] [28074] hci_rx_work: hci0 Event packet
[69713.867853] [28074] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.867857] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867858] [28074] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.867860] [28074] hci_sched_acl: hci0
[69713.867861] [28074] hci_sched_sco: hci0
[69713.867862] [28074] hci_sched_esco: hci0
[69713.867863] [28074] hci_sched_le: hci0
[69713.867865] [28074] hci_chan_sent: hci0
[69713.867888] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145661] [8909] hci_rx_work: hci0
[69714.145666] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 10
[69714.145676] [8909] hci_rx_work: hci0 ACL data packet
[69714.145679] [8909] hci_acldata_packet: hci0 len 6 handle 0x002d flags 0x0002
[69714.145681] [8909] hci_conn_enter_active_mode: hcon ffff88021f65a000 mode 0
[69714.145683] [8909] l2cap_recv_acldata: conn ffff880221005c00 len 6 flags 0x2
[69714.145693] [8909] l2cap_recv_frame: len 2, cid 0x0006
[69714.145696] [8909] hci_send_to_control: len 14
[69714.145710] [8909] smp_chan_destroy:
[69714.145713] [8909] pairing_complete: status 3
[69714.145714] [8909] cmd_complete: sock ffff88010323ac00
[69714.145717] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 3
[69714.145719] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145720] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69714.145722] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145724] [6450] bt_sock_poll: sock ffff8801db6b4f00, sk ffff880160351c00
...
[69714.145735] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145737] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 2
[69714.145739] [8909] l2cap_conn_del: hcon ffff88021f65a000 conn ffff880221005c00, err 13
[69714.145740] [6450] bt_sock_poll: sock ffff8801db6b5400, sk ffff88021e775000
[69714.145743] [6450] bt_sock_poll: sock ffff8801db6b5e00, sk ffff880160356000
[69714.145744] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 3
[69714.145746] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145748] [8909] l2cap_chan_del: chan ffff88005ede2c00, conn ffff880221005c00, err 13
[69714.145749] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 4
[69714.145751] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 1
[69714.145754] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145756] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 3
[69714.145759] [8909] hci_chan_del: hci0 hcon ffff88021f65a000 chan ffff88020d60b1c0
[69714.145766] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145787] [6515] hci_sock_release: sock ffff88005e75a080 sk ffff88010323ac00
[69714.146002] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
[69714.150795] [6450] l2cap_sock_release: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150799] [6450] l2cap_sock_shutdown: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150802] [6450] l2cap_chan_close: chan ffff88005ede2c00 state BT_CLOSED
[69714.150805] [6450] l2cap_sock_kill: sk ffff88005ede5800 state BT_CLOSED
[69714.150806] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 2
[69714.150808] [6450] l2cap_sock_destruct: sk ffff88005ede5800
[69714.150809] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 1
[69714.150811] [6450] l2cap_chan_destroy: chan ffff88005ede2c00
[69714.150970] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69714.151991] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 0
[69716.150339] [8909] hci_conn_timeout: hcon ffff88021f65a000 state BT_CONNECTED, refcnt -1

Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
mac80211: WEP extra head/tail room in ieee80211_send_auth

After skb allocation and call to ieee80211_wep_encrypt in ieee80211_send_auth
the flow fails with a warning in ieee80211_wep_add_iv on verification of
available head/tailroom needed for WEP_IV and WEP_ICV.

Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Revert "cfg80211: Use 5MHz bandwidth by default when checking usable channels"

This reverts commit 8eca1fb692cc9557f386eddce75c300a3855d11a.

Felix notes that this broke regulatory, leaving channel 12 open for AP
operation in the US regulatory domain where it isn't permitted.

Link: http://mid.gmane.org/53A6C0FF.9090104@openwrt.org
Reported-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: fix elapsed_jiffies calculation

MAX_JIFFY_OFFSET has no meaning when calculating the
elapsed jiffies, as jiffies run out until ULONG_MAX.

This miscalculation results in erroneous values
in case of a wrap-around.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bluetooth: Ignore H5 non-link packets in non-active state

When detecting a non-link packet, h5_reset_rx() frees the Rx skb.
Not returning after that will cause the upcoming h5_rx_payload()
call to dereference a now NULL Rx skb and trigger a kernel oops.

Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()

Currently, call_rcu() relies on implicit allocation and initialization
for the debug-objects handling of RCU callbacks.  If you hammer the
kernel hard enough with Sasha's modified version of trinity, you can end
up with the sl*b allocators recursing into themselves via this implicit
call_rcu() allocation.

This commit therefore exports the debug_init_rcu_head() and
debug_rcu_head_free() functions, which permits the allocators to allocated
and pre-initialize the debug-objects information, so that there no longer
any need for call_rcu() to do that initialization, which in turn prevents
the recursion into the memory allocators.

Reported-by: Sasha Levin <sasha.levin@oracle.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Looks-good-to: Christoph Lameter <cl@linux.com>
rcu: Reduce overhead of cond_resched() checks for RCU

Commit ac1bea85781e (Make cond_resched() report RCU quiescent states)
fixed a problem where a CPU looping in the kernel with but one runnable
task would give RCU CPU stall warnings, even if the in-kernel loop
contained cond_resched() calls.  Unfortunately, in so doing, it introduced
performance regressions in Anton Blanchard's will-it-scale "open1" test.
The problem appears to be not so much the increased cond_resched() path
length as an increase in the rate at which grace periods complete, which
increased per-update grace-period overhead.

This commit takes a different approach to fixing this bug, mainly by
moving the RCU-visible quiescent state from cond_resched() to
rcu_note_context_switch(), and by further reducing the check to a
simple non-zero test of a single per-CPU variable.  However, this
approach requires that the force-quiescent-state processing send
resched IPIs to the offending CPUs.  These will be sent only once
the grace period has reached an age specified by the boot/sysfs
parameter rcutree.jiffies_till_sched_qs, or once the grace period
reaches an age halfway to the point at which RCU CPU stall warnings
will be emitted, whichever comes first.

Reported-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
[ paulmck: Made rcu_momentary_dyntick_idle() as suggested by the
  ktest build robot.  Also fixed smp_mb() comment as noted by
  Oleg Nesterov. ]

Merge with e552592e (Reduce overhead of cond_resched() checks for RCU)

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
iwlwifi: mvm: rework sched scan channel configuration

The current sched scan channel configuration code
configures all the supported channels for scanning.

However, this can result in SYSASSERT in some cases,
when the configured channel is disabled.

Instead, configure only the channels given in the
req struct, and set the channel_count field appropriately.

While on it, change the code to use channel->hw_value
instead of recalculating the channel number.

Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
nl80211: move set_qos_map command into split state

The non-split wiphy state shouldn't be increased in size
so move the new set_qos_map command into the split if
statement.

Cc: stable@vger.kernel.org (3.14+)
Fixes: fa9ffc745610 ("cfg80211: Add support for QoS mapping")
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi: update the 7265 series HW IDs

Add one more 7265 series HW ID.
Edit one existing 7265 series HW ID.

CC: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Revert "iwlwifi: remove IWL_UCODE_TLV_FLAGS_UAPSD_SUPPORT flag"

This reverts commit dc9a19296a872644f19a06d8eeb5db222d327b41.

3610 cards don't support UAPSD.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: mvm: Fix broadcast filtering

Current code did not allow sending the broadcast filtering command
for P2P Client interfaces. However, this was not enough, since once
broadcast filtering command was issued over the station interface
after the P2P Client connected, the command also attached the filters
to the P2P Client MAC which is not allowed (FW ASSERT 1063).

Fix this skipping P2P Client interfaces when constructing the broadcast
filtering command

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: ArikX Nemtsov <arik@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>