cfg80211: sched_scan_mtx lock in cfg80211_conn_work()

Introduced in f9f475292dbb0e7035fb6661d1524761ea0888d9
("cfg80211: always check for scan end on P2P device")

cfg80211_conn_scan() which requires sched_scan_mtx to be held can be called
from cfg80211_conn_work(). Without this we are hitting multiple warnings like
the following:

WARNING: at net/wireless/sme.c:88 cfg80211_conn_scan+0x1dc/0x3a0 [cfg80211]()
Hardware name: 0578A21
Modules linked in: ...
Pid: 620, comm: kworker/3:1 Not tainted 3.9.0-rc4-next-20130328+ #326
Call Trace:
 [<c1036992>] warn_slowpath_common+0x72/0xa0
 [<c10369e2>] warn_slowpath_null+0x22/0x30
 [<faa4b0ec>] cfg80211_conn_scan+0x1dc/0x3a0 [cfg80211]
 [<faa4b344>] cfg80211_conn_do_work+0x94/0x380 [cfg80211]
 [<faa4c3b2>] cfg80211_conn_work+0xa2/0x130 [cfg80211]
 [<c1051858>] process_one_work+0x198/0x450

Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/mmu: On early bootup, flush the TLB when changing RO->RW bits Xen provided pagetables.

Occassionaly on a DL380 G4 the guest would crash quite early with this:

(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from ffffffff84dc7000:
(XEN)  L4[0x1ff] = 00000000c3f18067 0000000000001789
(XEN)  L3[0x1fe] = 00000000c3f14067 000000000000178d
(XEN)  L2[0x026] = 00000000dc8b2067 0000000000004def
(XEN)  L1[0x1c7] = 00100000dc8da067 0000000000004dc7
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 244 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3OVM  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff81263f22>]
(XEN) RFLAGS: 0000000000000216   EM: 1   CONTEXT: pv guest
(XEN) rax: 0000000000000000   rbx: ffffffff81785f88   rcx: 000000000000003f
(XEN) rdx: 0000000000000000   rsi: 00000000dc8da063   rdi: ffffffff84dc7000

The offending code shows it to be a loop writting the value zero
(%rax) in the %rdi (the L4 provided by Xen) register:

   0: 44 00 00             add    %r8b,(%rax)
   3: 31 c0                 xor    %eax,%eax
   5: b9 40 00 00 00       mov    $0x40,%ecx
   a: 66 0f 1f 84 00 00 00 nopw   0x0(%rax,%rax,1)
  11: 00 00
  13: ff c9                 dec    %ecx
  15:* 48 89 07             mov    %rax,(%rdi)     <-- trapping instruction
  18: 48 89 47 08           mov    %rax,0x8(%rdi)
  1c: 48 89 47 10           mov    %rax,0x10(%rdi)

which fails. xen_setup_kernel_pagetable recycles some of the Xen's
page-table entries when it has switched over to its Linux page-tables.

Right before try to clear the page, we  make a hypercall to change
it from _RO to  _RW and that works (otherwise we would hit an BUG()).
And the _RW flag is set for that page:
(XEN)  L1[0x1c7] = 001000004885f067 0000000000004dc7

The error code is 3, so PFEC_page_present and PFEC_write_access, so page is
present (correct), and we tried to write to the page, but a violation
occurred. The one theory is that the the page entries in hardware
(which are cached) are not up to date with what we just set. Especially
as we have just done an CR3 write and flushed the multicalls.

This patch does solve the problem by flusing out the TLB page
entry after changing it from _RO to _RW and we don't hit this
issue anymore.

Fixed-Oracle-Bug: 16243091 [ON OCCASIONS VM START GOES INTO
'CRASH' STATE: CLEAR_PAGE+0X12 ON HP DL380 G4]
Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
mwifiex: complete last internal scan

We are waiting on first scan command of internal scan request
before association, so we should complete on last internal scan
command response.

Cc: <stable@vger.kernel.org> # 3.8
Tested-by: Daniel Drake <dsd@laptop.org>
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: fix tkip mic tx/rx ap swap bug.

tx and rx michael tkip keys are always swapped in case being
configured per mac. This is wrong for AP. The swap should only
be done for STA mode.

Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: fix stopping AP.

on stop_ap the dongle was not properly shutdown. As a result it was
not possible to restart AP or STA after AP operation without
restarting the device. This patch will fix that.

Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: fix returning cipher_suite for get_key operation.

When multiple cipher suites have been programmed then the lowest
suite is to be retured. This fixes issue when AP mode is using
CCMP and TKIP WPA combination where rekeying will fail.

Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: do not proceed if fail to download nvram to dongle

Nvram contains critical initialization parameter for firmware to run. Host
driver should not proceed if nvram fails to be downloaded to dongle.

Reviewed-by: Piotr Haber <phaber@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: Re-enable interrupts after a channel change failure

ath_complete_reset will not be called if ath9k_hw_reset
is unsuccessful, so we need to re-enable intertupts to
balence the previous ath_prepare_reset call.  Also schedule a
reset as a best effort method to recover the chip from
whatever state caused the channel change failure.

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

Signed-off-by: Robert Shade <robert.shade@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
tty: Documentation: fix a path in a DocBook template

A wrong path to a driver breaks DocBook built.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: rt2x00pci_regbusy_read() - only print register access failure once

BugLink: http://bugs.launchpad.net/bugs/1128840

It appears that when this register read fails it never recovers, so
I think there is no need to repeat the same error message ad infinitum.

Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: users@rt2x00.serialmonkey.com
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: rt2x00pci: fix build error on Ralink RT3x5x SoCs

The rt2800pci driver supports the built-in wireless
MAC of the Ralink RT3x5x SoCs. However building the
driver for these SoCs leads to the following error:

    LD      init/built-in.o
  drivers/built-in.o: In function `rt2800pci_rxdone_tasklet':
  <...>/drivers/net/wireless/rt2x00/rt2800pci.c:1012: undefined reference to `rt2x00pci_rxdone'
  drivers/built-in.o:(.rodata+0x4780): undefined reference to `rt2x00pci_initialize'
  drivers/built-in.o:(.rodata+0x4784): undefined reference to `rt2x00pci_uninitialize'
  drivers/built-in.o:(.rodata+0x47bc): undefined reference to `rt2x00pci_flush_queue'
  drivers/built-in.o:(.rodata+0x4818): undefined reference to `rt2x00pci_regbusy_read'
  make[5]: *** [vmlinux] Error 1

The missing functions are provided by the rt2x00pci
module. This module is only selected by the rt2800pci
driver if PCI support is enabled in the kernel, because
some parts of the rt2x00pci code depends on PCI support.

PCI support is not available on the RT3x5x SoCs because
those have no PCI host controller at all.

Move the non PCI specific code from rt2x00pci into a
separate module. This makes it possible to use that
code even if PCI support is disabled. The affected
functions are used by all of the rt2x00 PCI drivers
so select the new module for those drivers.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
misc/vmw_vmci: Add dependency on CONFIG_NET

Building the vmw_vmci driver with CONFIG_NET undefined results in:

drivers/built-in.o: In function `__qp_memcpy_from_queue.isra.13':
vmci_queue_pair.c:(.text+0x1671a8): undefined reference to `memcpy_toiovec'
drivers/built-in.o: In function `__qp_memcpy_to_queue.isra.14':
vmci_queue_pair.c:(.text+0x167341): undefined reference to `memcpy_fromiovec'
make[1]: [vmlinux] Error 1 (ignored)

since memcpy_toiovec and memcpy_fromiovec are defined in the networking code.
Add the missing dependency.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OMAP/serial: Revert bad fix of Rx FIFO threshold granularity

Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2
that introduced regression reported by Paul Walmsley.

This commit restores setting granularity in SCR register
and adds note about comments below being inconsistent with
actual code.

Signed-off-by: Alexey Pelykh <alexey.pelykh@gmail.com>
Tested-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipv6/tcp: Stop processing ICMPv6 redirect messages

Tetja Rediske found that if the host receives an ICMPv6 redirect message
after sending a SYN+ACK, the connection will be reset.

He bisected it down to 093d04d (ipv6: Change skb->data before using
icmpv6_notify() to propagate redirect), but the origin of the bug comes
from ec18d9a26 (ipv6: Add redirect support to all protocol icmp error
handlers.). The bug simply did not trigger prior to 093d04d, because
skb->data did not point to the inner IP header and thus icmpv6_notify
did not call the correct err_handler.

This patch adds the missing "goto out;" in tcp_v6_err. After receiving
an ICMPv6 Redirect, we should not continue processing the ICMP in
tcp_v6_err, as this may trigger the removal of request-socks or setting
sk_err(_soft).

Reported-by: Tetja Rediske <tetja@tetja.de>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
atm: update msg_namelen in vcc_recvmsg()

The current code does not fill the msg_name member in case it is set.
It also does not set the msg_namelen member to 0 and therefore makes
net/socket.c leak the local, uninitialized sockaddr_storage variable
to userland -- 128 bytes of kernel stack memory.

Fix that by simply setting msg_namelen to 0 as obviously nobody cared
about vcc_recvmsg() not filling the msg_name in case it was set.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ax25: fix info leak via msg_name in ax25_recvmsg()

When msg_namelen is non-zero the sockaddr info gets filled out, as
requested, but the code fails to initialize the padding bytes of struct
sockaddr_ax25 inserted by the compiler for alignment. Additionally the
msg_namelen value is updated to sizeof(struct full_sockaddr_ax25) but is
not always filled up to this size.

Both issues lead to the fact that the code will leak uninitialized
kernel stack bytes in net/socket.c.

Fix both issues by initializing the memory with memset(0).

Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bluetooth: fix possible info leak in bt_sock_recvmsg()

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
early with 0 without updating the possibly set msg_namelen member. This,
in turn, leads to a 128 byte kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_stream_recvmsg().

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>