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>
SUNRPC: Remove extra xprt_put()

While testing error cases where rpc_new_client() fails, I saw
some oopses.

If rpc_new_client() fails, it already invokes xprt_put().  Thus
__rpc_clone_client() does not need to invoke it again.

Introduced by commit 1b63a751 "SUNRPC: Refactor rpc_clone_client()"
Fri Sep 14, 2012.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Cc: stable@vger.kernel.org [>=3.7]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
NFSv4: Fix a memory leak in nfs4_discover_server_trunking

When we assign a new rpc_client to clp->cl_rpcclient, we need to destroy
the old one.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: stable@vger.kernel.org [>=3.7]
NFSv4/4.1: Fix bugs in nfs4[01]_walk_client_list

It is unsafe to use list_for_each_entry_safe() here, because
when we drop the nn->nfs_client_lock, we pin the _current_ list
entry and ensure that it stays in the list, but we don't do the
same for the _next_ list entry. Use of list_for_each_entry() is
therefore the correct thing to do.

Also fix the refcounting in nfs41_walk_client_list().

Finally, ensure that the nfs_client has finished being initialised
and, in the case of NFSv4.1, that the session is set up.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Bryan Schumaker <bjschuma@netapp.com>
Cc: stable@vger.kernel.org [>= 3.7]
SUNRPC: Fix a potential memory leak in rpc_new_client

If the call to rpciod_up() fails, we currently leak a reference to the
struct rpc_xprt.
As part of the fix, we also remove the redundant check for xprt!=NULL.
This is already taken care of by the callers.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
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>