commit 22e994efa7f9a786fc2c5e07e0b5e312f2db025e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 11 18:49:02 2013 -0700

    Linux 3.10.6

commit d35fdd8cab944d7bc91cf9766dced16a1647e3cf
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Apr 23 15:39:50 2013 +0200

    hwrng: bcm2835: fix MODULE_LICENSE tag
    
    commit 22e8099f4f6621b8d165e238cdef2a1cf655e159 upstream.
    
    The MODULE_LICENSE macro invocation must use either "GPL" or "GPL v2",
    but not "GPLv2" in order to be detected by the module loader.
    
    This fixes the allmodconfig build error:
    
    FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Lubomir Rintel <lkundrak@v3.sk>
    Cc: Dom Cobley <popcornmix@gmail.com>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: linux-rpi-kernel@lists.infradead.org
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28f7544b8ba92b3975daa5b639ceb14ea2989d48
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 3 18:58:16 2013 +0200

    iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth
    
    commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream.
    
    The BT_CONFIG command that is sent to the device during
    startup will enable BT coex unless the module parameter
    turns it off, but on devices without Bluetooth this may
    cause problems, as reported in Redhat BZ 885407.
    
    Fix this by sending the BT_CONFIG command only when the
    device has Bluetooth.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0f5bc74eab416cea936f669e90a9d8a8dff18fd
Author: David Spinadel <david.spinadel@intel.com>
Date:   Tue Jul 23 14:13:32 2013 +0300

    iwlwifi: mvm: set SSID bits for passive channels
    
    commit bb963c4a43eb5127eb0bbfa16c7a6a209b0af5db upstream.
    
    Set SSID bitmap for direct scan even on passive channels,
    for the passive-to-active feature. Without this patch only
    the SSID from probe request template is sent on passive
    channels, after passive-to-active switching, causing us to
    not find all desired networks.
    
    Remove the unused passive scan mask constant.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: David Spinadel <david.spinadel@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7abe9b04d9531916a566828049284ae515dde9ea
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Aug 1 19:55:01 2013 +0300

    net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param
    
    [ Upstream commit b30513202c6c14120f70b2e9aa1e97d47bbc2313 ]
    
    Slaves get the 64B CQE/EQE state from QUERY_HCA, not from the module parameter.
    
    If the parameter is set to zero, the slave outputs an incorrect/irrelevant
    warning message that 64B CQEs/EQEs are supported but not enabled (even if the
    hypervisor has enabled 64B CQEs/EQEs).
    
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f870f0c92b820e063dbb6ba9bee0ee80e3dc8fd0
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Thu Aug 1 19:55:00 2013 +0300

    net/mlx4_core: Don't give VFs MAC addresses which are derived from the PF MAC
    
    [ Upstream commit 0508ad646836007e6e6b62331eee7356844eac3d ]
    
    If the user has not assigned a MAC address to a VM, then don't give it MAC which
    is based on the PF one. The current derivation scheme is wrong and leads to VM
    MAC collisions when the number of cards/hypervisors becomes big enough.
    
    Instead, just give it zeros and let them figure out what to do with that.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1eec0e843a893cf2893659ac99f8bd8ab6265ba4
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jul 31 09:03:56 2013 -0400

    8139cp: Add dma_mapping_error checking
    
    [ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]
    
    Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
    https://bugzilla.redhat.com/show_bug.cgi?id=947250
    
    It showed several backtraces arising for dma_map_* usage without checking the
    return code on the mapping.  Add the check and abort the rx/tx operation if its
    failed.  Untested as I have no hardware and the reporter has wandered off, but
    seems pretty straightforward.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 379731ab2b425538cf87437049ec1c1301605e46
Author: Joe Perches <joe@perches.com>
Date:   Tue Jul 30 10:31:00 2013 -0700

    ndisc: Add missing inline to ndisc_addr_option_pad
    
    [ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ]
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32976e6354d193eb47fd3e405cf22209782efe19
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jul 30 13:23:39 2013 +0300

    net_sched: info leak in atm_tc_dump_class()
    
    [ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]
    
    The "pvc" struct has a hole after pvc.sap_family which is not cleared.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ec05e6b8c709aa7f250a4ddc9fd4e423bf4cfd1
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jul 29 10:24:04 2013 -0700

    atl1c: use custom skb allocator
    
    [ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ]
    
    We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
    that using high order pages for skb allocations is problematic for atl1c
    
    We do not know exactly what the problem is, but we suspect that crossing
    4K pages is not well supported by this hardware.
    
    Use a custom allocator, using page allocator and 2K fragments for
    optimal stack behavior. We might make this allocator generic
    in future kernels.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d60b440872edd1160f0f2eb97fe3e305019c99f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun Jul 28 23:04:45 2013 +0300

    af_key: more info leaks in pfkey messages
    
    [ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
    
    This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
    messages".  There are some struct members which don't get initialized
    and could disclose small amounts of private information.
    
    Acked-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7515b17b548cfc509ccbe3fcf8d9f004356d1845
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jul 30 00:16:21 2013 -0700

    net_sched: Fix stack info leak in cbq_dump_wrr().
    
    [ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]
    
    Make sure the reserved fields, and padding (if any), are
    fully initialized.
    
    Based upon a patch by Dan Carpenter and feedback from
    Joe Perches.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1aa1e4cd9ea8a50f610c86ea324f9de4263ac4bc
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Jul 26 11:00:10 2013 +0200

    genetlink: release cb_lock before requesting additional module
    
    [ Upstream commit c74f2b2678f40b80265dd53556f1f778c8e1823f ]
    
    Requesting external module with cb_lock taken can result in
    the deadlock like showed below:
    
    [ 2458.111347] Showing all locks held in the system:
    [ 2458.111347] 1 lock held by NetworkManager/582:
    [ 2458.111347]  #0:  (cb_lock){++++++}, at: [<ffffffff8162bc79>] genl_rcv+0x19/0x40
    [ 2458.111347] 1 lock held by modprobe/603:
    [ 2458.111347]  #0:  (cb_lock){++++++}, at: [<ffffffff8162baa5>] genl_lock_all+0x15/0x30
    
    [ 2461.579457] SysRq : Show Blocked State
    [ 2461.580103]   task                        PC stack   pid father
    [ 2461.580103] NetworkManager  D ffff880034b84500  4040   582      1 0x00000080
    [ 2461.580103]  ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8
    [ 2461.580103]  ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff
    [ 2461.580103]  ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700
    [ 2461.580103] Call Trace:
    [ 2461.580103]  [<ffffffff817355f9>] schedule+0x29/0x70
    [ 2461.580103]  [<ffffffff81731ad1>] schedule_timeout+0x1c1/0x360
    [ 2461.580103]  [<ffffffff810e69eb>] ? mark_held_locks+0xbb/0x140
    [ 2461.580103]  [<ffffffff817377ac>] ? _raw_spin_unlock_irq+0x2c/0x50
    [ 2461.580103]  [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
    [ 2461.580103]  [<ffffffff81736398>] wait_for_completion_killable+0xe8/0x170
    [ 2461.580103]  [<ffffffff810b7fa0>] ? wake_up_state+0x20/0x20
    [ 2461.580103]  [<ffffffff81095825>] call_usermodehelper_exec+0x1a5/0x210
    [ 2461.580103]  [<ffffffff817362ed>] ? wait_for_completion_killable+0x3d/0x170
    [ 2461.580103]  [<ffffffff81095cc3>] __request_module+0x1b3/0x370
    [ 2461.580103]  [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
    [ 2461.580103]  [<ffffffff8162c5c9>] ctrl_getfamily+0x159/0x190
    [ 2461.580103]  [<ffffffff8162d8a4>] genl_family_rcv_msg+0x1f4/0x2e0
    [ 2461.580103]  [<ffffffff8162d990>] ? genl_family_rcv_msg+0x2e0/0x2e0
    [ 2461.580103]  [<ffffffff8162da1e>] genl_rcv_msg+0x8e/0xd0
    [ 2461.580103]  [<ffffffff8162b729>] netlink_rcv_skb+0xa9/0xc0
    [ 2461.580103]  [<ffffffff8162bc88>] genl_rcv+0x28/0x40
    [ 2461.580103]  [<ffffffff8162ad6d>] netlink_unicast+0xdd/0x190
    [ 2461.580103]  [<ffffffff8162b149>] netlink_sendmsg+0x329/0x750
    [ 2461.580103]  [<ffffffff815db849>] sock_sendmsg+0x99/0xd0
    [ 2461.580103]  [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
    [ 2461.580103]  [<ffffffff810e96e8>] ? lock_release_non_nested+0x308/0x350
    [ 2461.580103]  [<ffffffff815dbc6e>] ___sys_sendmsg+0x39e/0x3b0
    [ 2461.580103]  [<ffffffff810565af>] ? kvm_clock_read+0x2f/0x50
    [ 2461.580103]  [<ffffffff810218b9>] ? sched_clock+0x9/0x10
    [ 2461.580103]  [<ffffffff810bb2bd>] ? sched_clock_local+0x1d/0x80
    [ 2461.580103]  [<ffffffff810bb448>] ? sched_clock_cpu+0xa8/0x100
    [ 2461.580103]  [<ffffffff810e33ad>] ? trace_hardirqs_off+0xd/0x10
    [ 2461.580103]  [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
    [ 2461.580103]  [<ffffffff810e3f7f>] ? lock_release_holdtime.part.28+0xf/0x1a0
    [ 2461.580103]  [<ffffffff8120fec9>] ? fget_light+0xf9/0x510
    [ 2461.580103]  [<ffffffff8120fe0c>] ? fget_light+0x3c/0x510
    [ 2461.580103]  [<ffffffff815dd1d2>] __sys_sendmsg+0x42/0x80
    [ 2461.580103]  [<ffffffff815dd222>] SyS_sendmsg+0x12/0x20
    [ 2461.580103]  [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
    [ 2461.580103] modprobe        D ffff88000f2c8000  4632   603    602 0x00000080
    [ 2461.580103]  ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8
    [ 2461.580103]  ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500
    [ 2461.580103]  ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0
    [ 2461.580103] Call Trace:
    [ 2461.580103]  [<ffffffff817355f9>] schedule+0x29/0x70
    [ 2461.580103]  [<ffffffff81736d4d>] rwsem_down_write_failed+0xed/0x1a0
    [ 2461.580103]  [<ffffffff810bb200>] ? update_cpu_load_active+0x10/0xb0
    [ 2461.580103]  [<ffffffff8137b473>] call_rwsem_down_write_failed+0x13/0x20
    [ 2461.580103]  [<ffffffff8173492d>] ? down_write+0x9d/0xb2
    [ 2461.580103]  [<ffffffff8162baa5>] ? genl_lock_all+0x15/0x30
    [ 2461.580103]  [<ffffffff8162baa5>] genl_lock_all+0x15/0x30
    [ 2461.580103]  [<ffffffff8162cbb3>] genl_register_family+0x53/0x1f0
    [ 2461.580103]  [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
    [ 2461.580103]  [<ffffffff8162d650>] genl_register_family_with_ops+0x20/0x80
    [ 2461.580103]  [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
    [ 2461.580103]  [<ffffffffa017fe84>] nl80211_init+0x24/0xf0 [cfg80211]
    [ 2461.580103]  [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
    [ 2461.580103]  [<ffffffffa01dc043>] cfg80211_init+0x43/0xdb [cfg80211]
    [ 2461.580103]  [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0
    [ 2461.580103]  [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50
    [ 2461.580103]  [<ffffffff810f75af>] load_module+0x1c6f/0x27f0
    [ 2461.580103]  [<ffffffff810f2c90>] ? store_uevent+0x40/0x40
    [ 2461.580103]  [<ffffffff810f82c6>] SyS_finit_module+0x86/0xb0
    [ 2461.580103]  [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
    [ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1
    
    Problem start to happen after adding net-pf-16-proto-16-family-nl80211
    alias name to cfg80211 module by below commit (though that commit
    itself is perfectly fine):
    
    commit fb4e156886ce6e8309e912d8b370d192330d19d3
    Author: Marcel Holtmann <marcel@holtmann.org>
    Date:   Sun Apr 28 16:22:06 2013 -0700
    
        nl80211: Add generic netlink module alias for cfg80211/nl80211
    
    Reported-and-tested-by: Jeff Layton <jlayton@redhat.com>
    Reported-by: Richard W.M. Jones <rjones@redhat.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Reviewed-by: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebb72f8df2f7ecf3fce7f848fee47d1c5721901f
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 23 17:15:54 2013 -0700

    usbnet: do not pretend to support SG/TSO
    
    [ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]
    
    usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
    capabilities, as they allow TCP stack to build large TSO packets that
    need to be linearized and might use order-5 pages.
    
    This adds an extra copy overhead and possible allocation failures.
    
    Current code ignore skb_linearize() return code so crashes are even
    possible.
    
    Best is to not pretend SG/TSO is supported, and add this again when/if
    usbnet really supports SG for devices who could get a performance gain.
    
    Based on a prior patch from Freddy Xin <freddy@asix.com.tw>
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69af51cb5c56f310d9449150101bf25bd0d8a52d
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Mon Jul 22 23:45:53 2013 +0200

    ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup
    
    [ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]
    
    Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
    which leads to a panic (from Srivatsa S. Bhat):
    
    BUG: unable to handle kernel paging request at ffff882018552020
    IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
    PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
    Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
    Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
    +ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
    CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
    Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
    Workqueue: netns cleanup_net
    task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
    RIP: 0010:[<ffffffffa0366b02>]  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
    RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
    RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
    RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
    RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
    R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
    R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
    Stack:
     ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
     ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
     ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
    Call Trace:
     [<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6]
     [<ffffffff815bdecb>] inet_release+0xfb/0x220
     [<ffffffff815bddf2>] ? inet_release+0x22/0x220
     [<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6]
     [<ffffffff8151c1d9>] sock_release+0x29/0xa0
     [<ffffffff81525520>] sk_release_kernel+0x30/0x70
     [<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6]
     [<ffffffff8152fff9>] ops_exit_list+0x39/0x60
     [<ffffffff815306fb>] cleanup_net+0xfb/0x1a0
     [<ffffffff81075e3a>] process_one_work+0x1da/0x610
     [<ffffffff81075dc9>] ? process_one_work+0x169/0x610
     [<ffffffff81076390>] worker_thread+0x120/0x3a0
     [<ffffffff81076270>] ? process_one_work+0x610/0x610
     [<ffffffff8107da2e>] kthread+0xee/0x100
     [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
     [<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0
     [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
    Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
    RIP  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
     RSP <ffff881039367bd8>
    CR2: ffff882018552020
    
    Reported-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ff132a60d24baf89dd1af156a4659287ad0c531
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Tue Jul 23 00:17:25 2013 +0100

    sfc: Enable RX scatter for flows steered by RFS
    
    [ Upstream commit 7aa0076c497d6f0d5d957b431d0d80e1e9780274 ]
    
    Received packets are only scattered if this is enabled in both the
    matching filter and the receiving queue.  This was not being done for
    filters inserted for RFS, so any packet requiring more than a single
    descriptor was dropped.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c41d4725934c8a747c8157252ea53d76a0fdaece
Author: Michal Tesar <mtesar@redhat.com>
Date:   Fri Jul 19 14:09:01 2013 +0200

    sysctl net: Keep tcp_syn_retries inside the boundary
    
    [ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]
    
    Limit the min/max value passed to the
    /proc/sys/net/ipv4/tcp_syn_retries.
    
    Signed-off-by: Michal Tesar <mtesar@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 773c8fef67aa54c6533b26d5a162a1a3531e1d9f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 19 08:48:05 2013 +0300

    arcnet: cleanup sizeof parameter
    
    [ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]
    
    This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
    and sizeof(int) is 4, but the intent was to use the header size and not
    the sizeof the header size.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2281d42f6edb5934406cc1d32fa982e05b2ed41
Author: Christian Eggers <ceggers@gmx.de>
Date:   Mon Jul 29 20:54:09 2013 +0200

    spi: spi-davinci: Fix direction in dma_map_single()
    
    commit 89c66ee890af18500fa4598db300cc07c267f900 upstream.
    
    Commit 048177ce3b3962852fd34a7e04938959271c7e70 (spi: spi-davinci:
    convert to DMA engine API) introduced a regression: dma_map_single()
    is called with direction DMA_FROM_DEVICE for rx and for tx.
    
    Signed-off-by: Christian Eggers <ceggers@gmx.de>
    Acked-by: Matt Porter <mporter@ti.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d60f48be745bdaf0630b87e5720b2a9bbc16f33
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jul 17 07:13:59 2013 -0400

    x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset
    
    commit 803075dba31c17af110e1d9a915fe7262165b213 upstream.
    
    Recently we added an early quirk to detect 5500/5520 chipsets
    with early revisions that had problems with irq draining with
    interrupt remapping enabled:
    
      commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
      Author: Neil Horman <nhorman@tuxdriver.com>
      Date:   Tue Apr 16 16:38:32 2013 -0400
    
          iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets
    
    It turns out this same problem is present in the intel X58
    chipset as well. See errata 69 here:
    
      http://www.intel.com/content/www/us/en/chipsets/x58-express-specification-update.html
    
    This patch extends the pci early quirk so that the chip
    devices/revisions specified in the above update are also covered
    in the same way:
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Donald Dutile <ddutile@redhat.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    Cc: Malcolm Crossley <malcolm.crossley@citrix.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Don Zickus <dzickus@redhat.com>
    Link: http://lkml.kernel.org/r/1374059639-8631-1-git-send-email-nhorman@tuxdriver.com
    [ Small edits. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c5f9cd2b539879c4291fa24773795314e777354
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Aug 8 18:55:32 2013 +0200

    userns: limit the maximum depth of user_namespace->parent chain
    
    commit 8742f229b635bf1c1c84a3dfe5e47c814c20b5c8 upstream.
    
    Ensure that user_namespace->parent chain can't grow too much.
    Currently we use the hardroded 32 as limit.
    
    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c98ebcb618645d40cfec14b0534ff32126c114ce
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Aug 6 19:38:55 2013 +0200

    userns: unshare_userns(&cred) should not populate cred on failure
    
    commit 6160968cee8b90a5dd95318d716e31d7775c4ef3 upstream.
    
    unshare_userns(new_cred) does *new_cred = prepare_creds() before
    create_user_ns() which can fail. However, the caller expects that
    it doesn't need to take care of new_cred if unshare_userns() fails.
    
    We could change the single caller, sys_unshare(), but I think it
    would be more clean to avoid the side effects on failure, so with
    this patch unshare_userns() does put_cred() itself and initializes
    *new_cred only if create_user_ns() succeeeds.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73b8bd6de83c0ca182622f83d31a1b0a137281fe
Author: Shaohua Li <shli@kernel.org>
Date:   Thu Aug 1 09:56:36 2013 +0800

    workqueue: copy workqueue_attrs with all fields
    
    commit 2865a8fb44cc32420407362cbda80c10fa09c6b2 upstream.
    
     $echo '0' > /sys/bus/workqueue/devices/xxx/numa
     $cat /sys/bus/workqueue/devices/xxx/numa
    
    I got 1. It should be 0, the reason is copy_workqueue_attrs() called
    in apply_workqueue_attrs() doesn't copy no_numa field.
    
    Fix it by making copy_workqueue_attrs() copy ->no_numa too.  This
    would also make get_unbound_pool() set a pool's ->no_numa attribute
    according to the workqueue attributes used when the pool was created.
    While harmelss, as ->no_numa isn't a pool attribute, this is a bit
    confusing.  Clear it explicitly.
    
    tj: Updated description and comments a bit.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa2446744dd5a99a3938aad9faade9b8928aec48
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Thu Jul 25 10:18:17 2013 +0200

    s390/bitops: fix find_next_bit_left
    
    commit 3b0040a47ad63f7147e9e7d2febb61a3b564bb90 upstream.
    
    The find_next_bit_left function is broken if used with an offset which
    is not a multiple of 64. The shift to mask the bits of a 64-bit word
    not to search is in the wrong direction, the result can be either a
    bit found smaller than the offset or failure to find a set bit.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72e2729ea923cbbbeda03e5fce14f50b0707f724
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed Jul 24 10:35:33 2013 +0200

    s390: add support for IBM zBC12 machine
    
    commit 594712276e737961d30e11eae80d403b2b3815df upstream.
    
    Just add the new model number where appropiate.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21dd5ff6d6bd6be287e3e627f623075085eabb08
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 30 14:01:45 2013 +0200

    drm/i915: make SDVO TV-out work for multifunction devices
    
    commit 09ede5414f0215461c933032630bf9c3a61a8ba3 upstream.
    
    We need to track this correctly. While at it shovel the boolean
    to track whether the sdvo is in tv mode or not into pipe_config.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997
    Tested-by: Pierre Assal <pierre.assal@verint.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609
    Tested-by: cancan,feng <cancan.feng@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98ad9de66428f3dedb2081c7e0a505489d6feaf4
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Fri Jun 28 12:37:45 2013 +0800

    Btrfs: fix crash regarding to ulist_add_merge
    
    commit 35f0399db6658f465b00893bdd13b992a0acfef0 upstream.
    
    Several users reported this crash of NULL pointer or general protection,
    the story is that we add a rbtree for speedup ulist iteration, and we
    use krealloc() to address ulist growth, and krealloc() use memcpy to copy
    old data to new memory area, so it's OK for an array as it doesn't use
    pointers while it's not OK for a rbtree as it uses pointers.
    
    So krealloc() will mess up our rbtree and it ends up with crash.
    
    Reviewed-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Cc: BJ Quinn <bj@placs.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62fda513d368032d8f6b0375004032d5c0c6060d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 26 09:11:56 2013 -0700

    x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz
    
    commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.
    
    GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:
    
    		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
    		asm volatile("fxsave %0" : : "m" (fx_scratch));
    		mask = fx_scratch.mxcsr_mask;
    		if (mask == 0)
    			mask = 0x0000ffbf;
    
    to
    
    		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
    		asm volatile("fxsave %0" : : "m" (fx_scratch));
    		mask = 0x0000ffbf;
    
    since asm statement doesn’t say it will update fx_scratch.  As the
    result, the DAZ bit will be cleared.  This patch fixes it. This bug
    dates back to at least kernel 2.6.12.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ecbcde519f31f5ac76cfe34c99369da1c8a1d2c
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Jul 12 10:18:09 2013 -0400

    drm/radeon: never unpin UVD bo v3
    
    commit 9cc2e0e9f13315559c85c9f99f141e420967c955 upstream.
    
    Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU
    internally keeps pointers to it. Just keep it always pinned and save the
    content manually.
    
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425
    
    v2: fix compiler warning
    v3: fix CIK support
    v4: rebased for 3.10-stable tree
    
    Note: a version of this patch needs to go to stable.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a09a1b87004a8d574b41e56469005d70fdd2c201
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Jun 18 18:40:19 2013 +0800

    cgroup: fix umount vs cgroup_cfts_commit() race
    
    commit 084457f284abf6789d90509ee11dae383842b23b upstream.
    
    cgroup_cfts_commit() uses dget() to keep cgroup alive after cgroup_mutex
    is dropped, but dget() won't prevent cgroupfs from being umounted. When
    the race happens, vfs will see some dentries with non-zero refcnt while
    umount is in process.
    
    Keep running this:
      mount -t cgroup -o blkio xxx /cgroup
      umount /cgroup
    
    And this:
      modprobe cfq-iosched
      rmmod cfs-iosched
    
    After a while, the BUG() in shrink_dcache_for_umount_subtree() may
    be triggered:
    
      BUG: Dentry xxx{i=0,n=blkio.yyy} still in use (1) [umount of cgroup cgroup]
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0297fe5a50da955224e6e26c320383760edce01b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jul 8 15:59:40 2013 -0700

    fanotify: info leak in copy_event_to_user()
    
    commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.
    
    The ->reserved field isn't cleared so we leak one byte of stack
    information to userspace.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b9f3486bb756d0aa6c00d7f745c8ca65ff35f07
Author: Stéphane Marchesin <marcheu@chromium.org>
Date:   Fri Jul 12 13:54:41 2013 -0700

    drm/i915: Preserve the DDI_A_4_LANES bit from the bios
    
    commit bcf53de4e60d9000b82f541d654529e2902a4c2c upstream.
    
    Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes
    on eDP. This fixes eDP on hsw with > 2 lanes.
    
    Also s/port_reversal/saved_port_bits/ since the current name is
    confusing.
    
    Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Zhouping Liu <zliu@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu May 2 10:58:50 2013 +0200

    xen-blkfront: use a different scatterlist for each request
    
    commit b7649158a0d241f8d53d13ff7441858539e16656 upstream.
    
    In blkif_queue_request blkfront iterates over the scatterlist in order
    to set the segments of the request, and in blkif_completion blkfront
    iterates over the raw request, which makes it hard to know the exact
    position of the source and destination memory positions.
    
    This can be solved by allocating a scatterlist for each request, that
    will be keep until the request is finished, allowing us to copy the
    data back to the original memory without having to iterate over the
    raw request.
    
    Oracle-Bug: 16660413 - LARGE ASYNCHRONOUS READS APPEAR BROKEN ON 2.6.39-400
    CC: stable@vger.kernel.org
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reported-and-Tested-by: Anne Milicia <anne.milicia@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d56b0022c1cc6c63ab85f3bebcd8bf3dfe4be5ca
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jul 11 14:20:11 2013 -0400

    drm/radeon: Disable dma rings for bo moves on r6xx
    
    commit aeea40cbf9388fc829e66fa049f64d97fd72e118 upstream.
    
    They still seem to cause instability on some r6xx parts.
    As a follow up, we can switch to using CP DMA for bo
    moves on r6xx as a lighter weight alternative to using
    the 3D engine.
    
    A version of this patch should also go to stable kernels.
    
    Tested-by: J.N. <golden.fleeced@gmail.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f84f7159089e80f66733f8a196bdff2e0bc4f72
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Jul 25 06:31:38 2013 -0700

    PCI: Retry allocation of only the resource type that failed
    
    commit aa914f5ec25e4371ba18b312971314be1b9b1076 upstream.
    
    Ben Herrenschmidt reported the following problem:
    
      - The bus has space for all desired MMIO resources, including optional
        space for SR-IOV devices
      - We attempt to allocate I/O port space, but it fails because the bus
        has no I/O space
      - Because of the I/O allocation failure, we retry MMIO allocation,
        requesting only the required space, without the optional SR-IOV space
    
    This means we don't allocate the optional SR-IOV space, even though we
    could.
    
    This is related to 0c5be0cb0e ("PCI: Retry on IORESOURCE_IO type
    allocations").
    
    This patch changes how we handle allocation failures.  We will now retry
    allocation of only the resource type that failed.  If MMIO allocation
    fails, we'll retry only MMIO allocation.  If I/O port allocation fails,
    we'll retry only I/O port allocation.
    
    [bhelgaas: changelog]
    Reference: https://lkml.kernel.org/r/1367712653.11982.19.camel@pasglop
    Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5966904487a9a0cd4b9b6ac924cbac44704eb908
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Jul 19 12:14:16 2013 -0700

    PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device
    
    commit 29ed1f29b68a8395d5679b3c4e38352b617b3236 upstream.
    
    Hot-removing a device with SR-IOV enabled causes a null pointer dereference
    in v3.9 and v3.10.
    
    This is a regression caused by ba518e3c17 ("PCI: pciehp: Iterate over all
    devices in slot, not functions 0-7").  When we iterate over the
    bus->devices list, we first remove the PF, which also removes all the VFs
    from the list.  Then the list iterator blows up because more than just the
    current entry was removed from the list.
    
    ac205b7bb7 ("PCI: make sriov work with hotplug remove") works around a
    similar problem in pci_stop_bus_devices() by iterating over the list in
    reverse, so the VFs are stopped and removed from the list first, before the
    PF.
    
    This patch changes pciehp_unconfigure_device() to iterate over the list in
    reverse, too.
    
    [bhelgaas: bugzilla, changelog]
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60604
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d201a0b94daa5d8f7126c81678ccc04f9215772a
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Jul 27 01:41:34 2013 +0200

    Revert "cpuidle: Quickly notice prediction failure for repeat mode"
    
    commit 148519120c6d1f19ad53349683aeae9f228b0b8d upstream.
    
    Revert commit 69a37bea (cpuidle: Quickly notice prediction failure for
    repeat mode), because it has been identified as the source of a
    significant performance regression in v3.8 and later as explained by
    Jeremy Eder:
    
      We believe we've identified a particular commit to the cpuidle code
      that seems to be impacting performance of variety of workloads.
      The simplest way to reproduce is using netperf TCP_RR test, so
      we're using that, on a pair of Sandy Bridge based servers.  We also
      have data from a large database setup where performance is also
      measurably/positively impacted, though that test data isn't easily
      share-able.
    
      Included below are test results from 3 test kernels:
    
      kernel       reverts
      -----------------------------------------------------------
      1) vanilla   upstream (no reverts)
    
      2) perfteam2 reverts e11538d1f03914eb92af5a1a378375c05ae8520c
    
      3) test      reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4
                           e11538d1f03914eb92af5a1a378375c05ae8520c
    
      In summary, netperf TCP_RR numbers improve by approximately 4%
      after reverting 69a37beabf1f0a6705c08e879bdd5d82ff6486c4.  When
      69a37beabf1f0a6705c08e879bdd5d82ff6486c4 is included, C0 residency
      never seems to get above 40%.  Taking that patch out gets C0 near
      100% quite often, and performance increases.
    
      The below data are histograms representing the %c0 residency @
      1-second sample rates (using turbostat), while under netperf test.
    
      - If you look at the first 4 histograms, you can see %c0 residency
        almost entirely in the 30,40% bin.
      - The last pair, which reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4,
        shows %c0 in the 80,90,100% bins.
    
      Below each kernel name are netperf TCP_RR trans/s numbers for the
      particular kernel that can be disclosed publicly, comparing the 3
      test kernels.  We ran a 4th test with the vanilla kernel where
      we've also set /dev/cpu_dma_latency=0 to show overall impact
      boosting single-threaded TCP_RR performance over 11% above
      baseline.
    
      3.10-rc2 vanilla RX + c0 lock (/dev/cpu_dma_latency=0):
      TCP_RR trans/s 54323.78
    
      -----------------------------------------------------------
      3.10-rc2 vanilla RX (no reverts)
      TCP_RR trans/s 48192.47
    
      Receiver %c0
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     0]:
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [    59]:
      ***********************************************************
         40.0000 -    50.0000 [     1]: *
         50.0000 -    60.0000 [     0]:
         60.0000 -    70.0000 [     0]:
         70.0000 -    80.0000 [     0]:
         80.0000 -    90.0000 [     0]:
         90.0000 -   100.0000 [     0]:
    
      Sender %c0
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     0]:
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [    11]: ***********
         40.0000 -    50.0000 [    49]:
      *************************************************
         50.0000 -    60.0000 [     0]:
         60.0000 -    70.0000 [     0]:
         70.0000 -    80.0000 [     0]:
         80.0000 -    90.0000 [     0]:
         90.0000 -   100.0000 [     0]:
    
      -----------------------------------------------------------
      3.10-rc2 perfteam2 RX (reverts commit
      e11538d1f03914eb92af5a1a378375c05ae8520c)
      TCP_RR trans/s 49698.69
    
      Receiver %c0
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     1]: *
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [    59]:
      ***********************************************************
         40.0000 -    50.0000 [     0]:
         50.0000 -    60.0000 [     0]:
         60.0000 -    70.0000 [     0]:
         70.0000 -    80.0000 [     0]:
         80.0000 -    90.0000 [     0]:
         90.0000 -   100.0000 [     0]:
    
      Sender %c0
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     0]:
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [     2]: **
         40.0000 -    50.0000 [    58]:
      **********************************************************
         50.0000 -    60.0000 [     0]:
         60.0000 -    70.0000 [     0]:
         70.0000 -    80.0000 [     0]:
         80.0000 -    90.0000 [     0]:
         90.0000 -   100.0000 [     0]:
    
      -----------------------------------------------------------
      3.10-rc2 test RX (reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4
      and e11538d1f03914eb92af5a1a378375c05ae8520c)
      TCP_RR trans/s 47766.95
    
      Receiver %c0
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     1]: *
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [    27]: ***************************
         40.0000 -    50.0000 [     2]: **
         50.0000 -    60.0000 [     0]:
         60.0000 -    70.0000 [     2]: **
         70.0000 -    80.0000 [     0]:
         80.0000 -    90.0000 [     0]:
         90.0000 -   100.0000 [    28]: ****************************
    
      Sender:
          0.0000 -    10.0000 [     1]: *
         10.0000 -    20.0000 [     0]:
         20.0000 -    30.0000 [     0]:
         30.0000 -    40.0000 [    11]: ***********
         40.0000 -    50.0000 [     0]:
         50.0000 -    60.0000 [     1]: *
         60.0000 -    70.0000 [     0]:
         70.0000 -    80.0000 [     3]: ***
         80.0000 -    90.0000 [     7]: *******
         90.0000 -   100.0000 [    38]: **************************************
    
      These results demonstrate gaining back the tendency of the CPU to
      stay in more responsive, performant C-states (and thus yield
      measurably better performance), by reverting commit
      69a37beabf1f0a6705c08e879bdd5d82ff6486c4.
    
    Requested-by: Jeremy Eder <jeder@redhat.com>
    Tested-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9ef4410a75bea04e5f9e30c41fba0ebfa9b7559
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Jul 30 00:32:00 2013 +0200

    cpufreq: Fix cpufreq driver module refcount balance after suspend/resume
    
    commit 2a99859932281ed6c2ecdd988855f8f6838f6743 upstream.
    
    Since cpufreq_cpu_put() called by __cpufreq_remove_dev() drops the
    driver module refcount, __cpufreq_remove_dev() causes that refcount
    to become negative for the cpufreq driver after a suspend/resume
    cycle.
    
    This is not the only bad thing that happens there, however, because
    kobject_put() should only be called for the policy kobject at this
    point if the CPU is not the last one for that policy.
    
    Namely, if the given CPU is the last one for that policy, the
    policy kobject's refcount should be 1 at this point, as set by
    cpufreq_add_dev_interface(), and only needs to be dropped once for
    the kobject to go away.  This actually happens under the cpu == 1
    check, so it need not be done before by cpufreq_cpu_put().
    
    On the other hand, if the given CPU is not the last one for that
    policy, this means that cpufreq_add_policy_cpu() has been called
    at least once for that policy and cpufreq_cpu_get() has been
    called for it too.  To balance that cpufreq_cpu_get(), we need to
    call cpufreq_cpu_put() in that case.
    
    Thus, to fix the described problem and keep the reference
    counters balanced in both cases, move the cpufreq_cpu_get() call
    in __cpufreq_remove_dev() to the code path executed only for
    CPUs that share the policy with other CPUs.
    
    Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657e142082bec684725383eccd54e4ace5a2c293
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Jul 27 01:13:26 2013 +0200

    Revert "cpuidle: Quickly notice prediction failure in general case"
    
    commit 228b30234f258a193317874854eee1ca7807186e upstream.
    
    Revert commit e11538d1 (cpuidle: Quickly notice prediction failure in
    general case), since it depends on commit 69a37be (cpuidle: Quickly
    notice prediction failure for repeat mode) that has been identified
    as the source of a significant performance regression in v3.8 and
    later.
    
    Requested-by: Jeremy Eder <jeder@redhat.com>
    Tested-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6813e1d7dcf1db51970149e22f1524336a0bfa24
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Tue Jul 30 14:00:42 2013 +0200

    ACPI / battery: Fix parsing _BIX return value
    
    commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.
    
    The _BIX method returns extended battery info as a package.
    According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
    of that package should be "Revision".  However, the current ACPI
    battery driver treats the first member as "Power Unit" which should
    be the second member.  This causes the result of _BIX return data
    parsing to be incorrect.
    
    Fix this by adding a new member called 'revision' to struct
    acpi_battery and adding the offsetof() information on it to
    extended_info_offsets[] as the first row.
    
    [rjw: Changelog]
    Reported-and-tested-by: Jan Hoffmann <jan.christian.hoffmann@gmail.com>
    References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c181b464309da49333b85aa9df1eafe2678f1da3
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:27 2013 +0800

    zram: protect sysfs handler from invalid memory access
    
    commit 5863e10b441e7ea4b492f930f1be180a97d026f3 upstream.
    
    Use zram->init_lock to protect access to zram->meta, otherwise it
    may cause invalid memory access if zram->meta has been freed by
    zram_reset_device().
    
    This issue may be triggered by:
    Thread 1:
    while true; do cat mem_used_total; done
    Thread 2:
    while true; do echo 8M > disksize; echo 1 > reset; done
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 408fd687175ed6a1fea8cb901882c369ce1d4478
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:26 2013 +0800

    zram: avoid access beyond the zram device
    
    commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 upstream.
    
    Function valid_io_request() should verify the entire request are within
    the zram device address range. Otherwise it may cause invalid memory
    access when accessing/modifying zram->meta->table[index] because the
    'index' is out of range. Then it may access non-exist memory, randomly
    modify memory belong to other subsystems, which is hard to track down.
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7b071d02492426c5b5c1086fe082ba7a0de6de8
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:25 2013 +0800

    zram: avoid double free in function zram_bvec_write()
    
    commit 65c484609a3b25c35e4edcd5f2c38f98f5226093 upstream.
    
    When doing a patial write and the whole page is filled with zero,
    zram_bvec_write() will free uncmem twice.
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 916c68df544806585f63cc157149b9d9559ad500
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:24 2013 +0800

    zram: destroy all devices on error recovery path in zram_init()
    
    commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 upstream.
    
    On error recovery path of zram_init(), it leaks the zram device object
    causing the failure. So change create_device() to free allocated
    resources on error path.
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Acked-by: Jerome Marchand <jmarchan@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6349a112f4059ab32c1bb2fb644a2e63a620aeb5
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:23 2013 +0800

    zram: use zram->lock to protect zram_free_page() in swap free notify path
    
    commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.
    
    zram_slot_free_notify() is free-running without any protection from
    concurrent operations. So there are race conditions between
    zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
    and possible consequences include:
    1) Trigger BUG_ON(!handle) on zram_bvec_write() side.
    2) Access to freed pages on zram_bvec_read() side.
    3) Break some fields (bad_compress, good_compress, pages_stored)
       in zram->stats if the swap layer makes concurrently call to
       zram_slot_free_notify().
    
    So enhance zram_slot_free_notify() to acquire writer lock on zram->lock
    before calling zram_free_page().
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b74c38d5b6af46482480f6f8b83633e2971a0ed8
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:22 2013 +0800

    zram: avoid invalid memory access in zram_exit()
    
    commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream.
    
    Memory for zram->disk object may have already been freed after returning
    from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
    to access zram->disk again.
    
    We can't solve this bug by flipping the order of destroy_device(zram)
    and zram_reset_device(zram), that will cause deadlock issues to the
    zram sysfs handler.
    
    So fix it by holding an extra reference to zram->disk before calling
    destroy_device(zram).
    
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14d33c9b86b368fd6cab62e61074fa115018f1f8
Author: Avinash Patil <patila@marvell.com>
Date:   Mon Jul 29 16:32:38 2013 -0700

    mwifiex: fix wrong data rates in P2P client
    
    commit 237b2ac8ac89a6b0120decdd05c7bf4637deb98a upstream.
    
    This patch fixes an issue wherein adhoc rates were being copied
    into association request from P2P client.
    
    Signed-off-by: Avinash Patil <patila@marvell.com>
    Signed-off-by: Stone Piao <piaoyun@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 440166b9bb8b4fcd182531a65fd75816066f82f9
Author: Avinash Patil <patila@marvell.com>
Date:   Mon Jul 29 16:32:37 2013 -0700

    mwifiex: check for bss_role instead of bss_mode for STA operations
    
    commit 953b3539ef9301b8ef73f4b6e2fd824b86aae65a upstream.
    
    This patch fixes an issue wherein association would fail on P2P
    interfaces. This happened because we are checking priv->mode
    against NL80211_IFTYPE_STATION. While this check is correct for
    infrastructure stations, it would fail P2P clients for which mode
    is NL80211_IFTYPE_P2P_CLIENT.
    
    Better check would be bss_role which has only 2 values: STA/AP.
    
    Signed-off-by: Avinash Patil <patila@marvell.com>
    Signed-off-by: Stone Piao <piaoyun@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 558c62c2c0883b3c4f58c3baff021856eb4cb95b
Author: Tomasz Moń <desowin@gmail.com>
Date:   Tue Jul 23 07:42:49 2013 +0200

    mwifiex: Add missing endian conversion.
    
    commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.
    
    Both type and pkt_len variables are in host endian and these should be in
    Little Endian in the payload.
    
    Signed-off-by: Tomasz Moń <desowin@gmail.com>
    Acked-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c2c155d709f5bd3e8c1e9defddf8d74b1677eb1
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:   Sun Jul 28 13:17:22 2013 +0200

    rt2x00: fix stop queue
    
    commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.
    
    Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
    call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
    stop queue in mac80211.
    
    To fix that introduce rt2x00queue_pause_queue_nocheck() function,
    which will stop queue in mac80211 directly.
    
    Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.
    
    Note also that reordering operations i.e. first call to
    rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
    with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
    directly is the only available solution to fix the problem without
    major rework.
    
    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b36b789452df175f3bf7c8ffc929f1dd378f164
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Jul 31 14:11:14 2013 -0400

    svcrpc: fix kfree oops in gss-proxy code
    
    commit 743e217129f69aab074abe520a464fd0c6b1cca1 upstream.
    
    mech_oid.data is an array, not kmalloc()'d memory.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43110b3d902b62b9cd12aac237fcb471b4561e46
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Jun 10 16:06:44 2013 -0400

    svcrpc: fix gss_rpc_upcall create error
    
    commit 9f96392b0ae6aefc02a9b900c3f4889dfafc8402 upstream.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b9f570a271aca8b09d7e5325da0aa836a703ede
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Jun 7 10:11:19 2013 -0400

    svcrpc: fix gss-proxy xdr decoding oops
    
    commit dc43376c26cef74226174a2394f37f2a3f8a8639 upstream.
    
    Uninitialized stack data was being used as the destination for memcpy's.
    
    Longer term we'll just delete some of this code; all we're doing is
    skipping over xdr that we don't care about.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea788759177526b7a103baed9c711d284d822fe5
Author: Adam Lee <adam8157@gmail.com>
Date:   Wed Jul 10 10:02:12 2013 +0800

    Bluetooth: fix wrong use of PTR_ERR() in btusb
    
    commit d9c78e9738ccd0017b10b8f44462aafb61904a4a upstream.
    
    PTR_ERR() returns a signed long type value which is limited by IS_ERR(),
    it must be a negative number whose range is [-MAX_ERRNO, 0).
    
    The bug here returns negative numbers as error codes, then check it by
    "if (ret < 0)", but -PTR_ERR() is actually positive. The wrong use here
    leads to failure as below, even panic.
    
    [   12.958920] Bluetooth: hci0 command 0xfc8e tx timeout
    [   14.961765] Bluetooth: hci0 command 0xfc8e tx timeout
    [   16.964688] Bluetooth: hci0 command 0xfc8e tx timeout
    [   20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   22.957358] Bluetooth: hci0 command 0xfc8e tx timeout
    [   30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   32.951780] Bluetooth: hci0 command 0xfc8e tx timeout
    [   40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   42.946219] Bluetooth: hci0 command 0xfc8e tx timeout
    [   50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   52.940670] Bluetooth: hci0 command 0xfc8e tx timeout
    [   60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   62.935092] Bluetooth: hci0 command 0xfc8e tx timeout
    [   70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   72.929545] Bluetooth: hci0 command 0xfc8e tx timeout
    [   80.921111] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
    [   82.923969] Bluetooth: hci0 command 0xfc2f tx timeout
    [   90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed (-110)
    [   92.918406] Bluetooth: hci0 command 0xfc11 tx timeout
    [  100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed (-110)
    [  102.912858] Bluetooth: hci0 command 0xfc60 tx timeout
    [  110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed (-110)
    [  112.907293] Bluetooth: hci0 command 0xfc11 tx timeout
    [  120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110)
    [  120.904757] bluetoothd[1030]: segfault at 4 ip 00007f8b2eb55236 sp 00007fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000]
    
    Signed-off-by: Adam Lee <adam.lee@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c519774d4e636eeea2c1490c179fb898bbc61c17
Author: Cho, Yu-Chen <acho@suse.com>
Date:   Tue Jun 4 21:40:26 2013 +0800

    Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]
    
    commit 178c059e7640aa8e50213400c6f3dde00189d979 upstream.
    
    This patch adds support for Mediatek Bluetooth device
    
    T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=763f Rev= 1.00
    S:  Manufacturer=MediaTek
    S:  Product=BT
    S:  SerialNumber=1.0
    C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA
    A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:  If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    
    Signed-off-by: Cho, Yu-Chen <acho@suse.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eba6a13b3ca37f4b2c8abb7793f0931a5bfadc7b
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Thu Jun 20 13:38:45 2013 +0800

    Bluetooth: Add support for Atheros [0cf3:e003]
    
    commit 1d5b569ef85d013a775560a90050dc630614c045 upstream.
    
    Add support for the AR9462 chip
    
    T:  Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e003 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df235047f274553f8942286fef812fde4ec32a60
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Jul 17 11:27:40 2013 +0800

    Bluetooth: Add support for Atheros [0cf3:3121]
    
    commit 1ebd0b21ab14efb75950079840eac29afea2a26e upstream.
    
    Add support for the AR3012 chip.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=3121 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44c4127ace6fc02ff4e86318c11d90600874463e
Author: Sujith Manoharan <sujith@msujith.org>
Date:   Mon Jul 15 09:29:03 2013 +0530

    Bluetooth: ath3k: Add support for ID 0x13d3/0x3402
    
    commit 5b77a1f3d7b7360dc2b7c6d2188d39b9f8432907 upstream.
    
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3402 Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=59701
    
    Signed-off-by: Sujith Manoharan <sujith@msujith.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bc14767620b9ef79140de5fe73cd25006e2da5f
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Jul 8 10:27:23 2013 +0200

    Bluetooth: ath3k: don't use stack memory for DMA
    
    commit 517828a87994f41af6ae5a0f96f0f069f05baa81 upstream.
    
    Memory allocated by vmalloc (including stack) can not be used for DMA,
    i.e. data pointer on usb_control_msg() should not point to stack memory.
    
    Resolves:
    https://bugzilla.redhat.com/show_bug.cgi?id=977558
    
    Reported-and-tested-by: Andy Lawrence <dr.diesel@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4008b2c77e1b7175d3ed17e99e1afdc0ec531427
Author: Thomas Loo <tloo@saltstorm.net>
Date:   Wed Jul 3 02:53:54 2013 +0200

    Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]
    
    commit 84eb2ae1807dd1467bf6f500fc69ae61f1907b75 upstream.
    
    The Fujitsu Lifebook UH552/UH572 ships with a Qualcomm AR9462/AR3012
    WLAN/BT-Combo card.
    Add device ID to the ath3k driver to enable the bluetooth side of things.
    Patch against v3.10.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04c5 ProdID=1330 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Thomas Loo <tloo@saltstorm.net>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a8567af5be153e47347546ca0f772c206f1be8a
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sat Jul 20 21:46:48 2013 -0500

    ath: wil6210: Fix build error
    
    commit 5d21608a592a9afcac8d82c6478a564e911ce70b upstream.
    
    Building driver wil6210 in 3.10 and 3.11 kernels yields the following errors:
    
      CC [M]  drivers/net/wireless/ath/wil6210/debugfs.o
    drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_print_ring':
    drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
               false);
               ^
    In file included from include/linux/kernel.h:13:0,
                     from include/linux/cache.h:4,
                     from include/linux/time.h:4,
                     from include/linux/stat.h:18,
                     from include/linux/module.h:10,
                     from drivers/net/wireless/ath/wil6210/debugfs.c:17:
    include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
     extern void hex_dump_to_buffer(const void *buf, size_t len,
                 ^
    drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_txdesc_debugfs_show':
    drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
              sizeof(printbuf), false);
              ^
    In file included from include/linux/kernel.h:13:0,
                     from include/linux/cache.h:4,
                     from include/linux/time.h:4,
                     from include/linux/stat.h:18,
                     from include/linux/module.h:10,
                     from drivers/net/wireless/ath/wil6210/debugfs.c:17:
    include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
     extern void hex_dump_to_buffer(const void *buf, size_t len,
                 ^
    cc1: all warnings being treated as errors
    make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
    make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
    make[3]: *** [drivers/net/wireless/ath] Error 2
    make[2]: *** [drivers/net/wireless] Error 2
    make[1]: *** [drivers/net] Error 2
    make: *** [drivers] Error 2
    
    These errors are fixed by changing the type of the buffer from "unsigned char *" to "char *".
    
    Reported-by: Thomas Fjellstrom <thomas@fjellstrom.ca>
    Tested-by: Thomas Fjellstrom <thomas@fjellstrom.ca>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Thomas Fjellstrom <thomas@fjellstrom.ca>
    Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82056f561468aa59e697436742d460d939778175
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Jul 26 05:46:35 2013 -0700

    ixgbe: Fix Tx Hang issue with lldpad on 82598EB
    
    commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.
    
    This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
    Hangs on the card as soon as it attempts to configure DCB for the device. The
    adapter will continually Tx hang and reset in a loop.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Tested-by: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e30649e9650df1b772562525924c1f7453bf18d2
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Jul 23 13:56:50 2013 +0200

    mac80211: fix monitor interface suspend crash regression
    
    commit cd34f647a78e7f2296fcb72392b9e5c832793e65 upstream.
    
    My commit:
    
    commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
    Author: Stanislaw Gruszka <sgruszka@redhat.com>
    Date:   Thu Feb 28 10:55:26 2013 +0100
    
        mac80211: cleanup generic suspend/resume procedures
    
    removed check for deleting MONITOR and AP_VLAN when suspend. That can
    cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
    interface in the driver that we did not add before.
    
    Reference:
    http://marc.info/?l=linux-kernel&m=137391815113860&w=2
    
    Bisected-by: Ortwin Glück <odi@odi.ch>
    Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 090577c961e0843004762905bfcee2d6bf262722
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Mon Jul 8 10:43:31 2013 +0200

    mac80211: fix ethtool stats for non-station interfaces
    
    commit e13bae4f807401729b3f27c7e882a96b8b292809 upstream.
    
    As reported in https://bugzilla.kernel.org/show_bug.cgi?id=60514,
    the station loop never initialises 'sinfo' and therefore adds up
    a stack values, leaking stack information (the number of times it
    adds values is easily obtained another way.)
    
    Fix this by initialising the sinfo for each station to add.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd14e26686ae1729c25cf9c938eed826eb825e9d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jul 11 22:33:26 2013 +0200

    mac80211: fix duplicate retransmission detection
    
    commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.
    
    The duplicate retransmission detection code in mac80211
    erroneously attempts to do the check for every frame,
    even frames that don't have a sequence control field or
    that don't use it (QoS-Null frames.)
    
    This is problematic because it causes the code to access
    data beyond the end of the SKB and depending on the data
    there will drop packets erroneously.
    
    Correct the code to not do duplicate detection for such
    frames.
    
    I found this error while testing AP powersave, it lead
    to retransmitted PS-Poll frames being dropped entirely
    as the data beyond the end of the SKB was always zero.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Jun 28 21:04:35 2013 +0200

    mac80211/minstrel_ht: fix cck rate sampling
    
    commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
    
    The CCK group needs special treatment to set the right flags and rate
    index. Add this missing check to prevent setting broken rates for tx
    packets.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57fe9f79b907bdb8ef1fd8b31824f8901581369e
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Mon Jul 15 14:35:06 2013 +0200

    mac80211/minstrel: fix NULL pointer dereference issue
    
    commit 5c9fc93bc9bc417418fc1b6366833ae6a07b804d upstream.
    
    When priv_sta == NULL, mi->prev_sample is dereferenced too early. Move
    the assignment further down, after the rate_control_send_low call.
    
    Reported-by: Krzysztof Mazur <krzysiek@podlesie.net>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8942c6aac25cc5e98161c1a6b84b6ae10bff945
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Tue Jun 25 09:17:17 2013 +0200

    nl80211: fix mgmt tx status and testmode reporting for netns
    
    commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.
    
    These two events were sent to the default network
    namespace.
    
    This caused AP mode in a non-default netns to not
    work correctly. Mgmt tx status was multicasted to
    a different (default) netns instead of the one the
    AP was in.
    
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e59f8a9d54603dcadbee294849988d1876d4bd38
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Fri Jul 19 20:16:18 2013 +0200

    ath9k_htc: reboot firmware if it was loaded
    
    commit 4928bd2ef8ece262f4f314630219999a91eaa440 upstream.
    
    Currently ath9k_htc will reboot firmware only if interface was
    ever started. Which lead to the problem in case where interface
    was never started but module need to be reloaded.
    
    This patch will partially fix bug "ath9k_htc: Target is unresponsive"
    https://github.com/qca/open-ath9k-htc-firmware/issues/1
    
    Reproduction case:
    - plug adapter
    - make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
    - rmmod ath9k_htc; sleep 1; modprobe ath9k_htc
    
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6edab054ac50f1c248eacf4d750dcbf5ff4f00b6
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Fri Jul 19 20:16:17 2013 +0200

    ath9k_htc: do some initial hardware configuration
    
    commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.
    
    Currently we configure harwdare and clock, only after
    interface start. In this case, if we reload module or
    reboot PC without configuring adapter, firmware will freeze.
    There is no software way to reset adpter.
    
    This patch add initial configuration and set it in
    disabled state, to avoid this freeze. Behaviour of this patch
    should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.
    
    Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
    Tested-by: Bo Shi <cnshibo@gmail.com>
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fae60f7985950511751a2bd8adc71ba1049753da
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 24 13:55:51 2013 +0200

    iwlwifi: mvm: fix flushing not started aggregation sessions
    
    commit b6658ff80c43bcf84be0bbe371c88af1452e7776 upstream.
    
    When a not fully started aggregation session is destroyed
    and flushed, we get a warning, e.g.
    
      WARNING: at drivers/net/wireless/iwlwifi/pcie/tx.c:1142 iwl_trans_pcie_txq_disable+0x11c/0x160
      queue 16 not used
      Modules linked in: [...]
      Pid: 5135, comm: hostapd Tainted: G        W  O 3.5.0 #10
      Call Trace:
      wlan0: driver sets block=0 for sta 00:03:7f:10:44:d3
       [<ffffffff81036492>] warn_slowpath_common+0x72/0xa0
       [<ffffffff81036577>] warn_slowpath_fmt+0x47/0x50
       [<ffffffffa0368d6c>] iwl_trans_pcie_txq_disable+0x11c/0x160 [iwlwifi]
       [<ffffffffa03a2099>] iwl_mvm_sta_tx_agg_flush+0xe9/0x150 [iwlmvm]
       [<ffffffffa0396c43>] iwl_mvm_mac_ampdu_action+0xf3/0x1e0 [iwlmvm]
       [<ffffffffa0293ad3>] ___ieee80211_stop_tx_ba_session+0x193/0x920 [mac80211]
       [<ffffffffa0294ed8>] __ieee80211_stop_tx_ba_session+0x48/0x70 [mac80211]
       [<ffffffffa029159f>] ieee80211_sta_tear_down_BA_sessions+0x4f/0x80 [mac80211]
       [<ffffffffa028a686>] __sta_info_destroy+0x66/0x370 [mac80211]
       [<ffffffffa028abb4>] sta_info_destroy_addr_bss+0x44/0x70 [mac80211]
       [<ffffffffa02a3e26>] ieee80211_del_station+0x26/0x50 [mac80211]
       [<ffffffffa01e6395>] nl80211_del_station+0x85/0x200 [cfg80211]
    
    when a station deauthenticated from us without fully setting
    up the aggregation session.
    
    Fix this by checking the aggregation state before removing
    the hardware queue.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19a646b98d81a2b111d328ceca85f7e4b069b36a
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Jul 18 19:11:26 2013 +0300

    iwlwifi: add DELL SKU for 5150 HMC
    
    commit a1923f1d4723e5757cefdd60f7c7ab30e472007a upstream.
    
    This SKU was missing in the list of supported devices
    
    https://bugzilla.kernel.org/show_bug.cgi?id=60577
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 139ce60dd49cae12137947393917efb10bbcc219
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jul 4 15:55:29 2013 +0200

    iwlwifi: mvm: refuse connection to APs with BI < 16
    
    commit 48bc13072109ea58465542aa1ee31b4e1065468a upstream.
    
    Due to a firmware bug, it crashes when the beacon interval
    is smaller than 16. Avoid this by refusing the station state
    change creating the AP station, causing mac80211 to abandon
    the attempt to connect to the AP, and eventually wpa_s to
    blacklist it.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9bd9f5e484d91b89f022d40a925f2870502e4af
Author: David Spinadel <david.spinadel@intel.com>
Date:   Thu Jul 4 15:17:48 2013 +0300

    iwlwifi: mvm: fix bug in scan ssid
    
    commit fe04e83706037802c502ea41c0d1799ec35fc0d7 upstream.
    
    Increment index in each iteration. Without this increment we are
    overriding the added SSIDs and we will send only the last SSId
    and (n_ssids - 1) broadcast probes.
    
    Signed-off-by: David Spinadel <david.spinadel@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0e4964618515104556da8bd96cc6604ab8286e2
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Jul 2 13:35:35 2013 +0300

    iwlwifi: mvm: fix L2P BA ressources leak
    
    commit 93a426673fbfeae7fa6b27008828e2ac4c08dbee upstream.
    
    We didn't release the Rx AMPDU ressources properly.
    This bug led to firmware assert after 16 BA sessions.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 499c97f9a9ba379df5b246fe73c69c458bbcacd7
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sat Jul 27 13:34:42 2013 +0200

    USB: mos7840: fix pointer casts
    
    commit 683a0e4d7971c3186dc4d429027debfe309129aa upstream.
    
    Silence compiler warnings on 64-bit systems introduced by commit
    05cf0dec ("USB: mos7840: fix race in led handling") which uses the
    usb-serial data pointer to temporarily store the device type during
    probe but failed to add the required casts.
    
    [gregkh - change uintptr_t to unsigned long]
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62a2cfc242dd948a1edfe46681f553276a48cc7f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jul 26 11:55:19 2013 +0200

    USB: mos7840: fix race in led handling
    
    commit 05cf0dec5ccc696a7636c84b265b477173498156 upstream.
    
    Fix race in LED handling introduced by commit 0eafe4de ("USB: serial:
    mos7840: add support for MCS7810 devices") which reused the port control
    urb for manipulating the LED without making sure that the urb is not
    already in use. This could lead to the control urb being manipulated
    while in flight.
    
    Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy
    flag to handle concurrency.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed183fba4ecbc327570cd0655916cebaae918dcd
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jul 26 11:55:18 2013 +0200

    USB: mos7840: fix device-type detection
    
    commit 40c24f2893ba0ba7df485871f6aac0c197ceef5b upstream.
    
    Fix race in device-type detection introduced by commit 0eafe4de ("USB:
    serial: mos7840: add support for MCS7810 devices") which used a static
    variable to hold the device type.
    
    Move type detection to probe and use serial data to store the device
    type.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d614a64a0193ecc3c8d19774e9143173ad11af12
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jul 26 11:55:17 2013 +0200

    USB: mos7840: fix race in register handling
    
    commit d8a083cc746664916d9d36ed9e4d08a29525f245 upstream.
    
    Fix race in mos7840_get_reg which unconditionally manipulated the
    control urb (which may already be in use) by adding a control-urb busy
    flag.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b0f8f01765acdf7c84078b63d2e34c2b2dcafa8
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Jul 23 10:24:50 2013 +0200

    dma: pl330: Fix cyclic transfers
    
    commit fc51446021f42aca8906e701fc2292965aafcb15 upstream.
    
    Allocate a descriptor for each period of a cyclic transfer, not just the first.
    Also since the callback needs to be called for each finished period make sure to
    initialize the callback and callback_param fields of each descriptor in a cyclic
    transfer.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17e94a63470ddbd191bcc386f55f62987b58f912
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 28 11:49:41 2013 +0200

    serial/mxs-auart: increase time to wait for transmitter to become idle
    
    commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.
    
    Without this patch the driver waits ~1 ms for the UART to become idle. At
    115200n8 this time is (theoretically) enough to transfer 11.5 characters
    (= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
    of 16 characters the clock is gated too early. The problem is worse for
    lower baud rates.
    
    This only happens to really shut down the transmitter in the middle of a
    transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
    was at least once (because the bootloader doesn't disable the transmitter).
    
    So increase the timeout to 20 ms which should be enough for 9600n8, too.
    Moreover skip gating the clock if the timeout is elapsed.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ce440addcbede83e6eb6ad944eef8a894883552
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sun Jul 21 10:14:15 2013 +0800

    serial: arc_uart: Fix module alias
    
    commit d5a12ea7a9e58d9e5c19d25cb668aadb396423ec upstream.
    
    Platform drivers use "platform:" prefix in module alias.
    Also use DRIVER_NAME in MODULE_ALIAS to make module autoloading work.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15406011c343c3062cb2aa50b6173dfd87bb951b
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 4 11:28:51 2013 +0200

    serial/mxs-auart: fix race condition in interrupt handler
    
    commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.
    
    The handler needs to ack the pending events before actually handling them.
    Otherwise a new event might come in after it it considered non-pending or
    handled and is acked then without being handled. So this event is only
    noticed when the next interrupt happens.
    
    Without this patch an i.MX28 based machine running an rt-patched kernel
    regularly hangs during boot.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d54d012b636fe58770c4a58eda41de13fac40a0e
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Mon Jul 29 15:10:22 2013 +0530

    ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION
    
    commit a8d30608eaed6cc759b8e2e8a8bbbb42591f797f upstream.
    
    the return value of SNDRV_COMPRESS_VERSION always return default -ENOTTY as the
    return value was never updated for this call
    assign return value from put_user()
    
    Reported-by: Haynes <hgeorge@codeaurora.org>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6bffb8ffe2b9e42b09f4960cc623cecf2e9d778
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 1 08:38:27 2013 +0200

    ALSA: hda - Fix missing fixup for Mac Mini with STAC9221
    
    commit 697aebab78a88c6b164cfb74d19b86817d2ccd82 upstream.
    
    A fixup for Apple Mac Mini was lost during the adaption to the generic
    parser because the fallback for the generic ID 8384:7680 was dropped,
    and it resulted in the silence output (and maybe other problems).
    
    Unfortunately, just adding the missing subsystem ID wasn't enough, in
    this case.  The subsystem ID of this machine is 0000:0100 (what Apple
    thought...?), and since snd_hda_pick_fixup() doesn't take the vendor
    id zero into account, the driver ignored this entry.  Now it's fixed
    to regard the vendor id zero as a valid value.
    
    Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69325d97cb47677902ce3e873aeb1fe4abe7830f
Author: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date:   Tue Jul 30 17:14:34 2013 -0400

    hwmon: (max6697) fix MAX6581 ideality
    
    commit 5c52add19733eb36d8619713312f5604efef3502 upstream.
    
    Without this patch, the values for ideality (register 0x4b) and ideality
    selection mask (register 0x4c) are inverted.
    
    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a08a2ffd5719ed580862a2e525b8615a8b56a6d
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Tue Jul 30 02:02:16 2013 +0200

    parisc: Fix interrupt routing for C8000 serial ports
    
    commit dd5e6d6a3db09b16b7c222943977865eead88cc3 upstream.
    
    We can't use dev->mod_index for selecting the interrupt routing entry,
    because it's not an index into interrupt routing table. It will be even
    wrong on a machine with 2 CPUs (4 cores). But all needed information is
    contained in the PAT entries for the serial ports. mod[0] contains the
    iosapic address and mod_info has some indications for the interrupt
    input (at least it looks like it). This patch implements the searching
    for the right iosapic and uses this interrupt input information.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b81ed4057ca3d8a069b1d7f7919263b31776d208
Author: John David Anglin <dave.anglin@bell.net>
Date:   Tue Jul 23 12:27:52 2013 -0400

    parisc: Fix cache routines to ignore vma's with an invalid pfn
    
    commit 50861f5a02dbf939c27d35a26c472885e2844188 upstream.
    
    The parisc architecture does not have a pte special bit. As a result,
    special mappings are handled with the VM_PFNMAP and VM_MIXEDMAP flags.
    VM_MIXEDMAP mappings may or may not have a "struct page" backing. When
    pfn_valid() is false, there is no "struct page" backing. Otherwise, they
    are treated as normal pages.
    
    The FireGL driver uses the VM_MIXEDMAP without a backing "struct page".
    This treatment caused a panic due to a TLB data miss in
    update_mmu_cache. This appeared to be in the code generated for
    page_address(). We were in fact using a very circular bit of code to
    determine the physical address of the PFN in various cache routines.
    This wasn't valid when there was no "struct page" backing.  The needed
    address can in fact be determined simply from the PFN itself without
    using the "struct page".
    
    The attached patch updates update_mmu_cache(), flush_cache_mm(),
    flush_cache_range() and flush_cache_page() to check pfn_valid() and to
    directly compute the PFN physical and virtual addresses.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a3f7e9ec5c41da18fa1eec3cb9a2d3f2e5e14e3
Author: Alex Ivanov <gnidorah@p0n4ik.tk>
Date:   Wed Jul 10 21:14:55 2013 +0200

    parisc: agp/parisc-agp: allow binding of user memory to the AGP GART
    
    commit 06f0cce43a32bd2357cea1d8733bba48693d556b upstream.
    
    Allow binding of user memory to the AGP GART on systems with HP
    Quicksilver AGP bus. This resolves 'bind memory failed' error seen in
    dmesg:
    
     [29.365973] [TTM] AGP Bind memory failed.
     …
     [29.367030] [drm] Forcing AGP to PCI mode
    
    The system doesn't more fail to bind the memory, and hence not falling
    back to the PCI mode (if other failures aren't detected).
    
    This is just a simple write down from the following patches:
    agp/amd-k7: Allow binding user memory to the AGP GART
    agp/hp-agp: Allow binding user memory to the AGP GART
    
    Signed-off-by: Alex Ivanov <gnidorah@p0n4ik.tk>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 027798707afb90e6f08144955813ba575743b04d
Author: Robert Jennings <rcj@linux.vnet.ibm.com>
Date:   Wed Jul 24 20:13:21 2013 -0500

    powerpc: VPHN topology change updates all siblings
    
    commit 3be7db6ab45b21345386d1a466da133b19cde5e4 upstream.
    
    When an associativity level change is found for one thread, the
    siblings threads need to be updated as well.  This is done today
    for PRRN in stage_topology_update() but is missing for VPHN in
    update_cpu_associativity_changes_mask().  This patch will correctly
    update all thread siblings during a topology change.
    
    Without this patch a topology update can result in a CPU in
    init_sched_groups_power() getting stuck indefinitely in a loop.
    
    This loop is built in build_sched_groups(). As a result of the thread
    moving to a node separate from its siblings the struct sched_group will
    have its next pointer set to point to itself rather than the sched_group
    struct of the next thread.  This happens because we have a domain without
    the SD_OVERLAP flag, which is correct, and a topology that doesn't conform
    with reality (threads on the same core assigned to different numa nodes).
    When this list is traversed by init_sched_groups_power() it will reach
    the thread's sched_group structure and loop indefinitely; the cpu will
    be stuck at this point.
    
    The bug was exposed when VPHN was enabled in commit b7abef0 (v3.9).
    
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8148d0952b58d0664c3a3ddffbe6ded35ad4c790
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Jul 25 11:44:48 2013 +0100

    ARM: 7791/1: a.out: remove partial a.out support
    
    commit acfdd4b1f7590d02e9bae3b73bdbbc4a31b05d38 upstream.
    
    a.out support on ARM requires that argc, argv and envp are passed in
    r0-r2 respectively, which requires hacking load_aout_binary to
    prevent argc being clobbered by the return code. Whilst mainline kernels
    do set the registers up in start_thread, the aout loader has never
    carried the hack in mainline.
    
    Initialising the registers in this way actually goes against the libc
    expectations for ELF binaries, where argc, argv and envp are passed on
    the stack, with r0 being used to hold a pointer to an exit function for
    cleaning up after the dynamic linker if required. If the pointer is
    NULL, then it is ignored. When execing an ELF binary, Linux currently
    zeroes r0, then sets it to argc and then finally clobbers it with the
    return value of the execve syscall, so we actually end up with:
    
    	r0 = 0
    	stack[0] = argc
    	r1 = stack[1] = argv
    	r2 = stack[2] = envp
    
    libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
    works for user-spawned threads, but when executing an ELF binary from a
    kernel thread (via call_usermodehelper), the execve is performed on the
    ret_from_fork path, which restores r0 from the saved pt_regs, resulting
    in argc being presented to the C library. This has horrible consequences
    when the application exits, since we have an exit function registered
    using argc, resulting in a jump to hyperspace.
    
    This patch solves the problem by removing the partial a.out support from
    arch/arm/ altogether.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Cc: Ashish Sangwan <ashishsangwan2@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8271eb9ffaaa3390fb0478f94c88f91623b5af78
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue Jul 23 16:15:36 2013 +0100

    ARM: 7790/1: Fix deferred mm switch on VIVT processors
    
    commit bdae73cd374e28db544fdd9b77de689a36e3c129 upstream.
    
    As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
    pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
    finish_arch_post_lock_switch() function to avoid whole cache flushing
    with interrupts disabled. The need for deferred mm switch is stored as a
    thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
    have another thread switch before finish_arch_post_lock_switch(). If the
    new thread has the same mm as the previous 'next' thread, the scheduler
    will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
    the new thread.
    
    This patch moves the switch pending flag to the mm_context_t structure
    since this is specific to the mm rather than thread.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 340631138430a7ca215ca76ae74ef70f0be7ac20
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jul 15 14:26:19 2013 +0100

    ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2
    
    commit bf3f0f332f76a85ff3a0b393aaded5a8533769c0 upstream.
    
    Commit ae8a8b9553bd ("ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
    and use ALT_SMP instead") added early function returns for page table
    cache flushing operations on ARMv7 SMP CPUs.
    
    Unfortunately, when targetting Thumb-2, these `mov pc, lr' sequences
    assemble to 2 bytes which can lead to corruption of the instruction
    stream after code patching.
    
    This patch fixes the alternates to use wide (32-bit) instructions for
    Thumb-2, therefore ensuring that the patching code works correctly.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d67947d3a8ecd73a811e56613cc33d0a2126584
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Sun Jul 21 03:30:11 2013 +0300

    powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)
    
    commit fe956a1d4081ce1a959f87df397a15e252201f10 upstream.
    
    slots-fan on G5 Xserve is always running at full speed with windfarm_rm31
    driver, resulting in a very high acoustic noise level. It seems the fan
    parameters are incorrect, and have been copied from the Drive Bay fan
    (RPM, not present on rm31) of the legacy therm_pm72 driver. This patch
    changes the parameters to match the Slots fan (PWM) of therm_pm72. With
    the patch, slots-fan speed drops from 99% to 19% during normal use,
    and slots-temp settle to ~42'C.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a73f943a52c70cc33b29306433fb11cd9a854fc
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Aug 3 10:39:51 2013 +0100

    ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page)
    
    commit 8c0cc8a5d90bc7373a7a9e7f7a40eb41f51e03fc upstream.
    
    Olof reports that noMMU builds error out with:
    
    arch/arm/kernel/signal.c: In function 'setup_return':
    arch/arm/kernel/signal.c:413:25: error: 'mm_context_t' has no member named 'sigpage'
    
    This shows one of the evilnesses of IS_ENABLED().  Get rid of it here
    and replace it with #ifdef's - and as no noMMU platform can make use
    of sigpage, depend on CONIFG_MMU not CONFIG_ARM_MPU.
    
    Reported-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17ef32956a8481fba02751e14c17c648c9f472e6
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Aug 3 10:30:05 2013 +0100

    ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page)
    
    commit e0d407564b532d978b03ceccebd224a05d02f111 upstream.
    
    Unfortunately, I never committed the fix to a nasty oops which can
    occur as a result of that commit:
    
    ------------[ cut here ]------------
    kernel BUG at /home/olof/work/batch/include/linux/mm.h:414!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe0308 #53
    task: e90acac0 ti: e9be8000 task.ti: e9be8000
    PC is at special_mapping_fault+0xa4/0xc4
    LR is at __do_fault+0x68/0x48c
    
    This doesn't show up unless you do quite a bit of testing; a simple
    boot test does not do this, so all my nightly tests were passing fine.
    
    The reason for this is that install_special_mapping() expects the
    page array to stick around, and as this was only inserting one page
    which was stored on the kernel stack, that's why this was blowing up.
    
    Reported-by: Olof Johansson <olof@lixom.net>
    Tested-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75bc4446e0d553aceeb632ae05878786d6760e47
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Jul 31 21:58:56 2013 +0100

    ARM: make vectors page inaccessible from userspace
    
    commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream.
    
    If kuser helpers are not provided by the kernel, disable user access to
    the vectors page.  With the kuser helpers gone, there is no reason for
    this page to be visible to userspace.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5510daad56d3b9738d475957750db9d4fc607a9
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Jul 24 00:29:18 2013 +0100

    ARM: move signal handlers into a vdso-like page
    
    commit 48be69a026b2c17350a5ef18a1959a919f60be7d upstream.
    
    Move the signal handlers into a VDSO page rather than keeping them in
    the vectors page.  This allows us to place them randomly within this
    page, and also map the page at a random location within userspace
    further protecting these code fragments from ROP attacks.  The new
    VDSO page is also poisoned in the same way as the vector page.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c5db81779e0ab75fc2d71397911c546046f922f
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Jul 23 18:37:00 2013 +0100

    ARM: allow kuser helpers to be removed from the vector page
    
    commit f6f91b0d9fd971c630cef908dde8fe8795aefbf8 upstream.
    
    Provide a kernel configuration option to allow the kernel user helpers
    to be removed from the vector page, thereby preventing their use with
    ROP (return orientated programming) attacks.  This option is only
    visible for CPU architectures which natively support all the operations
    which kernel user helpers would normally provide, and must be enabled
    with caution.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6904e468bb92a726098a2dfcf792463e11053582
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Jul 9 01:03:17 2013 +0100

    ARM: update FIQ support for relocation of vectors
    
    commit e39e3f3ebfef03450cf7bfa7a974a8c61f7980c8 upstream.
    
    FIQ should no longer copy the FIQ code into the user visible vector
    page.  Instead, it should use the hidden page.  This change makes
    that happen.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0477cd427e4862843b6cfb460b83ca09f265742d
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Jul 4 12:03:31 2013 +0100

    ARM: use linker magic for vectors and vector stubs
    
    commit b9b32bf70f2fb710b07c94e13afbc729afe221da upstream.
    
    Use linker magic to create the vectors and vector stubs: we can tell the
    linker to place them at an appropriate VMA, but keep the LMA within the
    kernel.  This gets rid of some unnecessary symbol manipulation, and
    have the linker calculate the relocations appropriately.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b85796fa1987e014a61c379e3cb753976e993a46
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Jul 4 11:40:32 2013 +0100

    ARM: move vector stubs
    
    commit 19accfd373847ac3d10623c5d20f948846299741 upstream.
    
    Move the machine vector stubs into the page above the vector page,
    which we can prevent from being visible to userspace.  Also move
    the reset stub, and place the swi vector at a location that the
    'ldr' can get to it.
    
    This hides pointers into the kernel which could give valuable
    information to attackers, and reduces the number of exploitable
    instructions at a fixed address.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddc8d5e58a818e543ac658a572b3155c8ea3e45d
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Jul 4 11:32:04 2013 +0100

    ARM: poison memory between kuser helpers
    
    commit 5b43e7a383d69381ffe53423e46dd0fafae07da3 upstream.
    
    Poison the memory between each kuser helper.  This ensures that any
    branch between the kuser helpers will be appropriately trapped.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bde516f7a535b9bafa00e54a06c6538b9eb830e5
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Jul 4 11:00:23 2013 +0100

    ARM: poison the vectors page
    
    commit f928d4f2a86f46b030fa0850385b4391fc2b5918 upstream.
    
    Fill the empty regions of the vectors page with an exception generating
    instruction.  This ensures that any inappropriate branch to the vector
    page is appropriately trapped, rather than just encountering some code
    to execute.  (The vectors page was filled with zero before, which
    corresponds with the "andeq r0, r0, r0" instruction - a no-op.)
    
    Acked-by Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>