msm: pm: Remove idle wakelock checking

Now that all users of idle wakelocks are migrated to pm_qos we
can remove the idle wakelock checks from the pm code.

Change-Id: I19cca1d0b28a2943178b9d9eade2b594fd94a139
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Linux 3.0.72

commit ae7859181482fcfe38d9352bd0932fa45456bdd0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 5 10:18:27 2013 -0700

    Linux 3.0.72

commit f6cab49c7b11abf9595b1bf9b6ff73931c832e2e
Author: Veaceslav Falico <vfalico@redhat.com>
Date:   Tue Apr 2 05:15:16 2013 +0000

    bonding: get netdev_rx_handler_unregister out of locks

    [ Upstream commit fcd99434fb5c137274d2e15dd2a6a7455f0f29ff ]

    Now that netdev_rx_handler_unregister contains synchronize_net(), we need
    to call it outside of bond->lock, cause it might sleep. Also, remove the
    already unneded synchronize_net().

    Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
    Acked-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 31f516f1f359bed25b6f6ebe5752326145303b3c
Author: Joerg Roedel <joro@8bytes.org>
Date:   Tue Mar 26 22:48:23 2013 +0100

    iommu/amd: Make sure dma_ops are set for hotplug devices

    commit c2a2876e863356b092967ea62bebdb4dd663af80 upstream.

    There is a bug introduced with commit 27c2127 that causes
    devices which are hot unplugged and then hot-replugged to
    not have per-device dma_ops set. This causes these devices
    to not function correctly. Fixed with this patch.

    Reported-by: Andreas Degert <andreas.degert@googlemail.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5229aee5b9a28ac7b1c12ae988e1c8a49b217123
Author: Steve Glendinning <steve.glendinning@shawell.net>
Date:   Thu Mar 28 02:34:41 2013 +0000

    smsc75xx: fix jumbo frame support

    [ Upstream commit 4c51e53689569398d656e631c17308d9b8e84650 ]

    This patch enables RX of jumbo frames for LAN7500.

    Previously the driver would transmit jumbo frames succesfully but
    would drop received jumbo frames (incrementing the interface errors
    count).

    With this patch applied the device can succesfully receive jumbo
    frames up to MTU 9000 (9014 bytes on the wire including ethernet
    header).

    Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3beceaf660dffbe11f5a5606ea379666eb9eaad0
Author: Veaceslav Falico <vfalico@redhat.com>
Date:   Mon Mar 25 22:26:21 2013 +0000

    pch_gbe: fix ip_summed checksum reporting on rx

    [ Upstream commit 76a0e68129d7d24eb995a6871ab47081bbfa0acc ]

    skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that
    checksums were correct and CHECKSUM_NONE in any other case. They're
    currently placed vice versa, which breaks the forwarding scenario. Fix it
    by placing them as described above.

    Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb241ae254e1f4ee9a9f07e4a452b12cd674fffc
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 29 03:01:22 2013 +0000

    net: add a synchronize_net() in netdev_rx_handler_unregister()

    [ Upstream commit 00cfec37484761a44a3b6f4675a54caa618210ae ]

    commit 35d48903e97819 (bonding: fix rx_handler locking) added a race
    in bonding driver, reported by Steven Rostedt who did a very good
    diagnosis :

    <quoting Steven>

    I'm currently debugging a crash in an old 3.0-rt kernel that one of our
    customers is seeing. The bug happens with a stress test that loads and
    unloads the bonding module in a loop (I don't know all the details as
    I'm not the one that is directly interacting with the customer). But the
    bug looks to be something that may still be present and possibly present
    in mainline too. It will just be much harder to trigger it in mainline.

    In -rt, interrupts are threads, and can schedule in and out just like
    any other thread. Note, mainline now supports interrupt threads so this
    may be easily reproducible in mainline as well. I don't have the ability
    to tell the customer to try mainline or other kernels, so my hands are
    somewhat tied to what I can do.

    But according to a core dump, I tracked down that the eth irq thread
    crashed in bond_handle_frame() here:

            slave = bond_slave_get_rcu(skb->dev);
            bond = slave->bond; <--- BUG

    the slave returned was NULL and accessing slave->bond caused a NULL
    pointer dereference.

    Looking at the code that unregisters the handler:

    void netdev_rx_handler_unregister(struct net_device *dev)
    {

            ASSERT_RTNL();
            RCU_INIT_POINTER(dev->rx_handler, NULL);
            RCU_INIT_POINTER(dev->rx_handler_data, NULL);
    }

    Which is basically:
            dev->rx_handler = NULL;
            dev->rx_handler_data = NULL;

    And looking at __netif_receive_skb() we have:

            rx_handler = rcu_dereference(skb->dev->rx_handler);
            if (rx_handler) {
                    if (pt_prev) {
                            ret = deliver_skb(skb, pt_prev, orig_dev);
                            pt_prev = NULL;
                    }
                    switch (rx_handler(&skb)) {

    My question to all of you is, what stops this interrupt from happening
    while the bonding module is unloading?  What happens if the interrupt
    triggers and we have this:

            CPU0                    CPU1
            ----                    ----
      rx_handler = skb->dev->rx_handler

                            netdev_rx_handler_unregister() {
                               dev->rx_handler = NULL;
                               dev->rx_handler_data = NULL;

      rx_handler()
       bond_handle_frame() {
        slave = skb->dev->rx_handler;
        bond = slave->bond; <-- NULL pointer dereference!!!

    What protection am I missing in the bond release handler that would
    prevent the above from happening?

    </quoting Steven>

    We can fix bug this in two ways. First is adding a test in
    bond_handle_frame() and others to check if rx_handler_data is NULL.

    A second way is adding a synchronize_net() in
    netdev_rx_handler_unregister() to make sure that a rcu protected reader
    has the guarantee to see a non NULL rx_handler_data.

    The second way is better as it avoids an extra test in fast path.

    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jiri Pirko <jpirko@redhat.com>
    Cc: Paul E. McKenney <paulmck@us.ibm.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d2479580b8832251ab98dff289a88647e2d73bf
Author: Max.Nekludov@us.elster.com <Max.Nekludov@us.elster.com>
Date:   Fri Mar 29 05:27:36 2013 +0000

    ks8851: Fix interpretation of rxlen field.

    [ Upstream commit 14bc435ea54cb888409efb54fc6b76c13ef530e9 ]

    According to the Datasheet (page 52):
    15-12 Reserved
    11-0 RXBC Receive Byte Count
    This field indicates the present received frame byte size.

    The code has a bug:
                     rxh = ks8851_rdreg32(ks, KS_RXFHSR);
                     rxstat = rxh & 0xffff;
                     rxlen = rxh >> 16; // BUG!!! 0xFFF mask should be applied

    Signed-off-by: Max Nekludov <Max.Nekludov@us.elster.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79f0840fe9b4b304df53d24034744b6759352e17
Author: Hong Zhiguo <honkiko@gmail.com>
Date:   Tue Mar 26 01:52:45 2013 +0800

    ipv6: fix bad free of addrconf_init_net

    [ Upstream commit a79ca223e029aa4f09abb337accf1812c900a800 ]

    Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be409987531f89307e1cb281ff104209a085a5d7
Author: Mugunthan V N <mugunthanvnm@ti.com>
Date:   Thu Mar 28 18:10:50 2013 +0000

    atl1e: drop pci-msi support because of packet corruption

    [ Upstream commit 188ab1b105c96656f6bcfb49d0d8bb1b1936b632 ]

    Usage of pci-msi results in corrupted dma packet transfers to the host.

    Reported-by: rebelyouth <rebelyouth.hacklab@gmail.com>
    Cc: Huang, Xiong <xiong@qca.qualcomm.com>
    Tested-by: Christian Sünkenberg <christian.suenkenberg@student.kit.edu>
    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 85d17d2226b60776d55260f8bf5c5db972136e72
Author: Mugunthan V N <mugunthanvnm@ti.com>
Date:   Wed Mar 27 04:42:00 2013 +0000

    drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue

    To restart tx queue use netif_wake_queue() intead of netif_start_queue()
    so that net schedule will restart transmission immediately which will
    increase network performance while doing huge data transfers.

    Reported-by: Dan Franke <dan.franke@schneider-electric.com>
    Suggested-by: Sriramakrishnan A G <srk@ti.com>
    Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
    Acked-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 5a37b9a3f61eced85a8398250f2fc89dbfdf1a10
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 27 18:28:41 2013 +0000

    aoe: reserve enough headroom on skbs

    [ Upstream commit 91c5746425aed8f7188a351f1224a26aa232e4b3 ]

    Some network drivers use a non default hard_header_len

    Transmitted skb should take into account dev->hard_header_len, or risk
    crashes or expensive reallocations.

    In the case of aoe, lets reserve MAX_HEADER bytes.

    David reported a crash in defxx driver, solved by this patch.

    Reported-by: David Oostdyk <daveo@ll.mit.edu>
    Tested-by: David Oostdyk <daveo@ll.mit.edu>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Ed Cashin <ecashin@coraid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92a33e58656098d3dbf538b3c1c86e6fcfbccb6c
Author: Paul Moore <pmoore@redhat.com>
Date:   Mon Mar 25 03:18:33 2013 +0000

    unix: fix a race condition in unix_release()

    [ Upstream commit ded34e0fe8fe8c2d595bfa30626654e4b87621e0 ]

    As reported by Jan, and others over the past few years, there is a
    race condition caused by unix_release setting the sock->sk pointer
    to NULL before properly marking the socket as dead/orphaned.  This
    can cause a problem with the LSM hook security_unix_may_send() if
    there is another socket attempting to write to this partially
    released socket in between when sock->sk is set to NULL and it is
    marked as dead/orphaned.  This patch fixes this by only setting
    sock->sk to NULL after the socket has been marked as dead; I also
    take the opportunity to make unix_release_sock() a void function
    as it only ever returned 0/success.

    Dave, I think this one should go on the -stable pile.

    Special thanks to Jan for coming up with a reproducer for this
    problem.

    Reported-by: Jan Stancek <jan.stancek@gmail.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cbf0cbd285ef39202743ecfd62b4fe2dcdc81fd
Author: Masatake YAMATO <yamato@redhat.com>
Date:   Mon Apr 1 14:50:40 2013 -0400

    thermal: shorten too long mcast group name

    [ Upstream commits 73214f5d9f33b79918b1f7babddd5c8af28dd23d
      and f1e79e208076ffe7bad97158275f1c572c04f5c7, the latter
      adds an assertion to genetlink to prevent this from happening
      again in the future. ]

    The original name is too long.

    Signed-off-by: Masatake YAMATO <yamato@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9829fe9806e22d7a822f4c947cc432c8d1774b54
Author: Cong Wang <amwang@redhat.com>
Date:   Fri Mar 22 19:14:07 2013 +0000

    8021q: fix a potential use-after-free

    [ Upstream commit 4a7df340ed1bac190c124c1601bfc10cde9fb4fb ]

    vlan_vid_del() could possibly free ->vlan_info after a RCU grace
    period, however, we may still refer to the freed memory area
    by 'grp' pointer. Found by code inspection.

    This patch moves vlan_vid_del() as behind as possible.

    Signed-off-by: Cong Wang <amwang@redhat.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: "David S. Miller" <davem@davemloft.net>
    Acked-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 01326198867ce1ab1bb26acb48de7b06eab571fe
Author: Yuchung Cheng <ycheng@google.com>
Date:   Sun Mar 24 10:42:25 2013 +0000

    tcp: undo spurious timeout after SACK reneging

    [ Upstream commit 7ebe183c6d444ef5587d803b64a1f4734b18c564 ]

    On SACK reneging the sender immediately retransmits and forces a
    timeout but disables Eifel (undo). If the (buggy) receiver does not
    drop any packet this can trigger a false slow-start retransmit storm
    driven by the ACKs of the original packets. This can be detected with
    undo and TCP timestamps.

    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06551316b51c5f140c29748011c37057cb7ba932
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 21 17:36:09 2013 +0000

    tcp: preserve ACK clocking in TSO

    [ Upstream commit f4541d60a449afd40448b06496dcd510f505928e ]

    A long standing problem with TSO is the fact that tcp_tso_should_defer()
    rearms the deferred timer, while it should not.

    Current code leads to following bad bursty behavior :

    20:11:24.484333 IP A > B: . 297161:316921(19760) ack 1 win 119
    20:11:24.484337 IP B > A: . ack 263721 win 1117
    20:11:24.485086 IP B > A: . ack 265241 win 1117
    20:11:24.485925 IP B > A: . ack 266761 win 1117
    20:11:24.486759 IP B > A: . ack 268281 win 1117
    20:11:24.487594 IP B > A: . ack 269801 win 1117
    20:11:24.488430 IP B > A: . ack 271321 win 1117
    20:11:24.489267 IP B > A: . ack 272841 win 1117
    20:11:24.490104 IP B > A: . ack 274361 win 1117
    20:11:24.490939 IP B > A: . ack 275881 win 1117
    20:11:24.491775 IP B > A: . ack 277401 win 1117
    20:11:24.491784 IP A > B: . 316921:332881(15960) ack 1 win 119
    20:11:24.492620 IP B > A: . ack 278921 win 1117
    20:11:24.493448 IP B > A: . ack 280441 win 1117
    20:11:24.494286 IP B > A: . ack 281961 win 1117
    20:11:24.495122 IP B > A: . ack 283481 win 1117
    20:11:24.495958 IP B > A: . ack 285001 win 1117
    20:11:24.496791 IP B > A: . ack 286521 win 1117
    20:11:24.497628 IP B > A: . ack 288041 win 1117
    20:11:24.498459 IP B > A: . ack 289561 win 1117
    20:11:24.499296 IP B > A: . ack 291081 win 1117
    20:11:24.500133 IP B > A: . ack 292601 win 1117
    20:11:24.500970 IP B > A: . ack 294121 win 1117
    20:11:24.501388 IP B > A: . ack 295641 win 1117
    20:11:24.501398 IP A > B: . 332881:351881(19000) ack 1 win 119

    While the expected behavior is more like :

    20:19:49.259620 IP A > B: . 197601:202161(4560) ack 1 win 119
    20:19:49.260446 IP B > A: . ack 154281 win 1212
    20:19:49.261282 IP B > A: . ack 155801 win 1212
    20:19:49.262125 IP B > A: . ack 157321 win 1212
    20:19:49.262136 IP A > B: . 202161:206721(4560) ack 1 win 119
    20:19:49.262958 IP B > A: . ack 158841 win 1212
    20:19:49.263795 IP B > A: . ack 160361 win 1212
    20:19:49.264628 IP B > A: . ack 161881 win 1212
    20:19:49.264637 IP A > B: . 206721:211281(4560) ack 1 win 119
    20:19:49.265465 IP B > A: . ack 163401 win 1212
    20:19:49.265886 IP B > A: . ack 164921 win 1212
    20:19:49.266722 IP B > A: . ack 166441 win 1212
    20:19:49.266732 IP A > B: . 211281:215841(4560) ack 1 win 119
    20:19:49.267559 IP B > A: . ack 167961 win 1212
    20:19:49.268394 IP B > A: . ack 169481 win 1212
    20:19:49.269232 IP B > A: . ack 171001 win 1212
    20:19:49.269241 IP A > B: . 215841:221161(5320) ack 1 win 119

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Van Jacobson <vanj@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Nandita Dukkipati <nanditad@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40e954e2b1e8f84eb1e0eb7af49bf4b9baa8a0ac
Author: Mirko Lindner <mlindner@marvell.com>
Date:   Tue Mar 26 06:38:42 2013 +0000

    sky2: Threshold for Pause Packet is set wrong

    [ Upstream commit 74f9f42c1c1650e74fb464f76644c9041f996851 ]

    The sky2 driver sets the Rx Upper Threshold for Pause Packet generation to a
    wrong value which leads to only 2kB of RAM remaining space. This can lead to
    Rx overflow errors even with activated flow-control.

    Fix: We should increase the value to 8192/8

    Signed-off-by: Mirko Lindner <mlindner@marvell.com>
    Acked-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b1a48cbcca9aa5aeed944c88c3d2b7c745d6f37
Author: Mirko Lindner <mlindner@marvell.com>
Date:   Tue Mar 26 06:38:35 2013 +0000

    sky2: Receive Overflows not counted

    [ Upstream commit 9cfe8b156c21cf340b3a10ecb3022fbbc1c39185 ]

    The sky2 driver doesn't count the Receive Overflows because the MAC
    interrupt for this event is not set in the MAC's interrupt mask.
    The MAC's interrupt mask is set only for Transmit FIFO Underruns.

    Fix: The correct setting should be (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR)
    Otherwise the Receive Overflow event will not generate any interrupt.
    The  Receive Overflow interrupt is handled correctly

    Signed-off-by: Mirko Lindner <mlindner@marvell.com>
    Acked-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 396db58dbf922549ccc9c4c779419d9163da3224
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Mar 14 15:03:53 2013 -0400

    tracing: Prevent buffer overwrite disabled for latency tracers

    commit 613f04a0f51e6e68ac6fe571ab79da3c0a5eb4da upstream.

    The latency tracers require the buffers to be in overwrite mode,
    otherwise they get screwed up. Force the buffers to stay in overwrite
    mode when latency tracers are enabled.

    Added a flag_changed() method to the tracer structure to allow
    the tracers to see what flags are being changed, and also be able
    to prevent the change from happing.

    [Backported for 3.4-stable. Re-added current_trace NULL checks; removed
    allocated_snapshot field; adapted to tracing_trace_options_write without
    trace_set_options.]

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9736c0eed0bfe68c89a269c89c3483d39ea1c83
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Mar 14 13:50:56 2013 -0400

    tracing: Protect tracer flags with trace_types_lock

    commit 69d34da2984c95b33ea21518227e1f9470f11d95 upstream.

    Seems that the tracer flags have never been protected from
    synchronous writes. Luckily, admins don't usually modify the
    tracing flags via two different tasks. But if scripts were to
    be used to modify them, then they could get corrupted.

    Move the trace_types_lock that protects against tracers changing
    to also protect the flags being set.

    [Backported for 3.4, 3.0-stable. Moved return to after unlock.]

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 503f4bdcc078e7abee273a85ce322de81b18a224
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Mar 11 23:39:59 2013 -0400

    ext4: use atomic64_t for the per-flexbg free_clusters count

    commit 90ba983f6889e65a3b506b30dc606aa9d1d46cd2 upstream.

    A user who was using a 8TB+ file system and with a very large flexbg
    size (> 65536) could cause the atomic_t used in the struct flex_groups
    to overflow.  This was detected by PaX security patchset:

    http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551

    This bug was introduced in commit 9f24e4208f7e, so it's been around
    since 2.6.30.  :-(

    Fix this by using an atomic64_t for struct orlav_stats's
    free_clusters.

    [Backported for 3.0-stable. Renamed free_clusters back to free_blocks;
    fixed a few more atomic_read's of free_blocks left in 3.0.]

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fb54baf47818c2a76999ff907e2cecf25b98218
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Thu Mar 7 11:59:14 2013 +0000

    efivars: Handle duplicate names from get_next_variable()

    commit e971318bbed610e28bb3fde9d548e6aaf0a6b02e upstream.

    Some firmware exhibits a bug where the same VariableName and
    VendorGuid values are returned on multiple invocations of
    GetNextVariableName(). See,

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

    As a consequence of such a bug, Andre reports hitting the following
    WARN_ON() in the sysfs code after updating the BIOS on his, "Gigabyte
    Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F19e
    11/21/2012)" machine,

    [    0.581554] EFI Variables Facility v0.08 2004-May-17
    [    0.584914] ------------[ cut here ]------------
    [    0.585639] WARNING: at /home/andre/linux/fs/sysfs/dir.c:536 sysfs_add_one+0xd4/0x100()
    [    0.586381] Hardware name: To be filled by O.E.M.
    [    0.587123] sysfs: cannot create duplicate filename '/firmware/efi/vars/SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8'
    [    0.588694] Modules linked in:
    [    0.589484] Pid: 1, comm: swapper/0 Not tainted 3.8.0+ #7
    [    0.590280] Call Trace:
    [    0.591066]  [<ffffffff81208954>] ? sysfs_add_one+0xd4/0x100
    [    0.591861]  [<ffffffff810587bf>] warn_slowpath_common+0x7f/0xc0
    [    0.592650]  [<ffffffff810588bc>] warn_slowpath_fmt+0x4c/0x50
    [    0.593429]  [<ffffffff8134dd85>] ? strlcat+0x65/0x80
    [    0.594203]  [<ffffffff81208954>] sysfs_add_one+0xd4/0x100
    [    0.594979]  [<ffffffff81208b78>] create_dir+0x78/0xd0
    [    0.595753]  [<ffffffff81208ec6>] sysfs_create_dir+0x86/0xe0
    [    0.596532]  [<ffffffff81347e4c>] kobject_add_internal+0x9c/0x220
    [    0.597310]  [<ffffffff81348307>] kobject_init_and_add+0x67/0x90
    [    0.598083]  [<ffffffff81584a71>] ? efivar_create_sysfs_entry+0x61/0x1c0
    [    0.598859]  [<ffffffff81584b2b>] efivar_create_sysfs_entry+0x11b/0x1c0
    [    0.599631]  [<ffffffff8158517e>] register_efivars+0xde/0x420
    [    0.600395]  [<ffffffff81d430a7>] ? edd_init+0x2f5/0x2f5
    [    0.601150]  [<ffffffff81d4315f>] efivars_init+0xb8/0x104
    [    0.601903]  [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
    [    0.602659]  [<ffffffff81d05d80>] kernel_init_freeable+0x13e/0x1c6
    [    0.603418]  [<ffffffff81d05586>] ? loglevel+0x31/0x31
    [    0.604183]  [<ffffffff816a6530>] ? rest_init+0x80/0x80
    [    0.604936]  [<ffffffff816a653e>] kernel_init+0xe/0xf0
    [    0.605681]  [<ffffffff816ce7ec>] ret_from_fork+0x7c/0xb0
    [    0.606414]  [<ffffffff816a6530>] ? rest_init+0x80/0x80
    [    0.607143] ---[ end trace 1609741ab737eb29 ]---

    There's not much we can do to work around and keep traversing the
    variable list once we hit this firmware bug. Our only solution is to
    terminate the loop because, as Lingzhu reports, some machines get
    stuck when they encounter duplicate names,

      > I had an IBM System x3100 M4 and x3850 X5 on which kernel would
      > get stuck in infinite loop creating duplicate sysfs files because,
      > for some reason, there are several duplicate boot entries in nvram
      > getting GetNextVariableName into a circle of iteration (with
      > period > 2).

    Also disable the workqueue, as efivar_update_sysfs_entries() uses
    GetNextVariableName() to figure out which variables have been created
    since the last iteration. That algorithm isn't going to work if
    GetNextVariableName() returns duplicates. Note that we don't disable
    EFI variable creation completely on the affected machines, it's just
    that any pstore dump-* files won't appear in sysfs until the next
    boot.

    [Backported for 3.0-stable. Removed code related to pstore
    workqueue but pulled in helper function variable_is_present
    from a93bc0c; Moved the definition of __efivars to the top
    for being referenced in variable_is_present.]

    Reported-by: Andre Heider <a.heider@gmail.com>
    Reported-by: Lingzhu Xiang <lxiang@redhat.com>
    Tested-by: Lingzhu Xiang <lxiang@redhat.com>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ff0153d27b39d87c1ff5f575c4ca7b52f33381
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Fri Mar 1 14:49:12 2013 +0000

    efivars: explicitly calculate length of VariableName

    commit ec50bd32f1672d38ddce10fb1841cbfda89cfe9a upstream.

    It's not wise to assume VariableNameSize represents the length of
    VariableName, as not all firmware updates VariableNameSize in the same
    way (some don't update it at all if EFI_SUCCESS is returned). There
    are even implementations out there that update VariableNameSize with
    values that are both larger than the string returned in VariableName
    and smaller than the buffer passed to GetNextVariableName(), which
    resulted in the following bug report from Michael Schroeder,

      > On HP z220 system (firmware version 1.54), some EFI variables are
      > incorrectly named :
      >
      > ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns
      > /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
      > /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
      > /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
      > /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c

    The issue here is that because we blindly use VariableNameSize without
    verifying its value, we can potentially read garbage values from the
    buffer containing VariableName if VariableNameSize is larger than the
    length of VariableName.

    Since VariableName is a string, we can calculate its size by searching
    for the terminating NULL character.

    [Backported for 3.8-stable. Removed workqueue code added in
    a93bc0c 3.9-rc1.]

    Reported-by: Frederic Crozat <fcrozat@suse.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Michael Schroeder <mls@suse.com>
    Cc: Lee, Chun-Yi <jlee@suse.com>
    Cc: Lingzhu Xiang <lxiang@redhat.com>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22b2f9aaf4d832e4eef1b8a437e64db5f2f147d1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Feb 22 16:53:38 2013 +0200

    drm/i915: Don't clobber crtc->fb when queue_flip fails

    commit 4a35f83b2b7c6aae3fc0d1c4554fdc99dc33ad07 upstream.

    Restore crtc->fb to the old framebuffer if queue_flip fails.

    While at it, kill the pointless intel_fb temp variable.

    v2: Update crtc->fb before queue_flip and restore it back
        after a failure.

    [Backported for 3.0-stable. Adjusted context. Please
    cherry-pick commit 7317c75e66fce0c9f82fbe6f72f7e5256b315422
    upstream before this patch as it provides necessary context
    and fixes a panic.]

    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reported-and-Tested-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08b2dce495f36f35e2759446a0ed94c66a05a0c5
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Aug 29 09:45:28 2011 -0700

    drm/i915: don't set unpin_work if vblank_get fails

    commit 7317c75e66fce0c9f82fbe6f72f7e5256b315422 upstream.

    This fixes a race where we may try to finish a page flip and decrement
    the refcount even if our vblank_get failed and we ended up with a
    spurious flip pending interrupt.

    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=34211.

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e36f505caf7882b6cc89ecedcd7f26749ef917a
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Mar 26 14:11:13 2013 -0400

    nfsd4: reject "negative" acl lengths

    commit 64a817cfbded8674f345d1117b117f942a351a69 upstream.

    Since we only enforce an upper bound, not a lower bound, a "negative"
    length can get through here.

    The symptom seen was a warning when we attempt to a kmalloc with an
    excessive size.

    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 582b4c3dc62284aec367a3f4f74ce8101303e9c4
Author: Anatol Pomozov <anatol.pomozov@gmail.com>
Date:   Mon Apr 1 09:47:56 2013 -0700

    loop: prevent bdev freeing while device in use

    commit c1681bf8a7b1b98edee8b862a42c19c4e53205fd upstream.

    struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
    block_device allocated first time we access /dev/loopXX and deallocated on
    bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
    we want that block_device stay alive until we destroy the loop device
    with "losetup -d".

    But because we do not hold /dev/loopXX inode its counter goes 0, and
    inode/bdev can be destroyed at any moment. Usually it happens at memory
    pressure or when user drops inode cache (like in the test below). When later in
    loop_clr_fd() we want to use bdev we have use-after-free error with following
    stack:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
      bd_set_size+0x10/0xa0
      loop_clr_fd+0x1f8/0x420 [loop]
      lo_ioctl+0x200/0x7e0 [loop]
      lo_compat_ioctl+0x47/0xe0 [loop]
      compat_blkdev_ioctl+0x341/0x1290
      do_filp_open+0x42/0xa0
      compat_sys_ioctl+0xc1/0xf20
      do_sys_open+0x16e/0x1d0
      sysenter_dispatch+0x7/0x1a

    To prevent use-after-free we need to grab the device in loop_set_fd()
    and put it later in loop_clr_fd().

    The issue is reprodusible on current Linus head and v3.3. Here is the test:

      dd if=/dev/zero of=loop.file bs=1M count=1
      while [ true ]; do
        losetup /dev/loop0 loop.file
        echo 2 > /proc/sys/vm/drop_caches
        losetup -d /dev/loop0
      done

    [ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
      time we call loop_set_fd() we check that loop_device->lo_state is
      Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
      it will get EBUSY.  And if we try to loop_clr_fd() on unbound loop
      device we'll get ENXIO.

      loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
      loop_device->lo_ctl_mutex. ]

    Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 956fc762ae9fb5f8cf6cd456f508ad431a4653b7
Author: Petr Matousek <pmatouse@redhat.com>
Date:   Tue Mar 19 12:36:59 2013 +0100

    KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461)

    commit 6d1068b3a98519247d8ba4ec85cd40ac136dbdf9 upstream.

    On hosts without the XSAVE support unprivileged local user can trigger
    oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
    cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
    ioctl.

    invalid opcode: 0000 [#2] SMP
    Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
    ...
    Pid: 24935, comm: zoog_kvm_monito Tainted: G      D      3.2.0-3-686-pae
    EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
    EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
    EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
    ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
    task.ti=d7c62000)
    Stack:
     00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
     ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
     c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
    Call Trace:
     [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
    ...
     [<c12bfb44>] ? syscall_call+0x7/0xb
    Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
    1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
    d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
    EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
    0068:d7c63e70

    QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
    and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
    out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
    X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
    X86_FEATURE_XSAVE even on hosts that do not support it, might be
    susceptible to this attack from inside the guest as well.

    Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.

    Signed-off-by: Petr Matousek <pmatouse@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9e61dba0c73294e9e6761f290dce2049f06bfac
Author: Jiang Liu <jiang.liu@huawei.com>
Date:   Tue Mar 19 12:36:58 2013 +0100

    mm/hotplug: correctly add new zone to all other nodes' zone lists

    commit 08dff7b7d629807dbb1f398c68dd9cd58dd657a1 upstream.

    When online_pages() is called to add new memory to an empty zone, it
    rebuilds all zone lists by calling build_all_zonelists().  But there's a
    bug which prevents the new zone to be added to other nodes' zone lists.

    online_pages() {
    	build_all_zonelists()
    	.....
    	node_set_state(zone_to_nid(zone), N_HIGH_MEMORY)
    }

    Here the node of the zone is put into N_HIGH_MEMORY state after calling
    build_all_zonelists(), but build_all_zonelists() only adds zones from
    nodes in N_HIGH_MEMORY state to the fallback zone lists.
    build_all_zonelists()

        ->__build_all_zonelists()
    	->build_zonelists()
    	    ->find_next_best_node()
    		->for_each_node_state(n, N_HIGH_MEMORY)

    So memory in the new zone will never be used by other nodes, and it may
    cause strange behavor when system is under memory pressure.  So put node
    into N_HIGH_MEMORY state before calling build_all_zonelists().

    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Jiang Liu <liuj97@gmail.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Keping Chen <chenkeping@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16df76518569ae25da4c3750ad4bab65ef2aa900
Author: Avi Kivity <avi@redhat.com>
Date:   Tue Mar 19 12:36:57 2013 +0100

    KVM: Fix buffer overflow in kvm_set_irq()

    commit f2ebd422f71cda9c791f76f85d2ca102ae34a1ed upstream.

    kvm_set_irq() has an internal buffer of three irq routing entries, allowing
    connecting a GSI to three IRQ chips or on MSI.  However setup_routing_entry()
    does not properly enforce this, allowing three irqchip routes followed by
    an MSI route to overflow the buffer.

    Fix by ensuring that an MSI entry is added to an empty list.

    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1cc80b94858666cc48467e8e166ccf389551b5d
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Mar 19 12:36:56 2013 +0100

    macvtap: zerocopy: validate vectors before building skb

    commit b92946e2919134ebe2a4083e4302236295ea2a73 upstream.

    There're several reasons that the vectors need to be validated:

    - Return error when caller provides vectors whose num is greater than UIO_MAXIOV.
    - Linearize part of skb when userspace provides vectors grater than MAX_SKB_FRAGS.
    - Return error when userspace provides vectors whose total length may exceed
    - MAX_SKB_FRAGS * PAGE_SIZE.

    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Benjamin Poirier <bpoirier@suse.de> [patch reduced to
    					the 3rd reason only for 3.0]
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8868daebc1b6240d07d5c6428f8bc8631b2bed42
Author: Avi Kivity <avi@redhat.com>
Date:   Tue Mar 19 12:36:55 2013 +0100

    KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

    commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream.

    If some vcpus are created before KVM_CREATE_IRQCHIP, then
    irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
    to potential NULL pointer dereferences.

    Fix by:
    - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
    - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP

    This is somewhat long winded because vcpu->arch.apic is created without
    kvm->lock held.

    Based on earlier patch by Michael Ellerman.

    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c34b4ae8f8228e1ec083be0333426eca4a31357
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Mar 19 12:36:54 2013 +0100

    NFS: nfs_getaclargs.acl_len is a size_t

    commit 56d08fef2369d5ca9ad2e1fc697f5379fd8af751 upstream.

    Squelch compiler warnings:

    fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’:
    fs/nfs/nfs4proc.c:3811:14: warning: comparison between signed and
    	unsigned integer expressions [-Wsign-compare]
    fs/nfs/nfs4proc.c:3818:15: warning: comparison between signed and
    	unsigned integer expressions [-Wsign-compare]

    Introduced by commit bf118a34 "NFSv4: include bitmap in nfsv4 get
    acl data", Dec 7, 2011.

    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01b140abad66f022ff6dff7cc1307b07281035fa
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Mar 19 12:36:53 2013 +0100

    NFSv4: Fix an Oops in the NFSv4 getacl code

    commit 331818f1c468a24e581aedcbe52af799366a9dfe upstream.

    Commit bf118a342f10dafe44b14451a1392c3254629a1f (NFSv4: include bitmap
    in nfsv4 get acl data) introduces the 'acl_scratch' page for the case
    where we may need to decode multi-page data. However it fails to take
    into account the fact that the variable may be NULL (for the case where
    we're not doing multi-page decode), and it also attaches it to the
    encoding xdr_stream rather than the decoding one.

    The immediate result is an Oops in nfs4_xdr_enc_getacl due to the
    call to page_address() with a NULL page pointer.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Andy Adamson <andros@netapp.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c938c22b48302eeb9a6f3cc83f223f37d98ba6f7
Author: Andy Adamson <andros@netapp.com>
Date:   Tue Mar 19 12:36:52 2013 +0100

    NFSv4: include bitmap in nfsv4 get acl data

    commit bf118a342f10dafe44b14451a1392c3254629a1f upstream.

    The NFSv4 bitmap size is unbounded: a server can return an arbitrary
    sized bitmap in an FATTR4_WORD0_ACL request.  Replace using the
    nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
    with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
    xdr length to the (cached) acl page data.

    This is a general solution to commit e5012d1f "NFSv4.1: update
    nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
    when getting ACLs.

    Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
    was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.

    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0072625c351588b8fde9e6f46fb60ba2e521fb47
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Mar 19 12:36:51 2013 +0100

    KVM: x86: Prevent starting PIT timers in the absence of irqchip support

    commit 0924ab2cfa98b1ece26c033d696651fd62896c69 upstream.

    User space may create the PIT and forgets about setting up the irqchips.
    In that case, firing PIT IRQs will crash the host:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
    IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm]
    ...
    Call Trace:
     [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm]
     [<ffffffff81071431>] process_one_work+0x111/0x4d0
     [<ffffffff81071bb2>] worker_thread+0x152/0x340
     [<ffffffff81075c8e>] kthread+0x7e/0x90
     [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10

    Prevent this by checking the irqchip mode before starting a timer. We
    can't deny creating the PIT if the irqchips aren't set up yet as
    current user land expects this order to work.

    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e8e2c7847cc17a8135ad17869f5ba37207e2f89
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue Mar 19 12:36:50 2013 +0100

    batman-adv: Only write requested number of byte to user buffer

    commit b5a1eeef04cc7859f34dec9b72ea1b28e4aba07c upstream.

    Don't write more than the requested number of bytes of an batman-adv icmp
    packet to the userspace buffer. Otherwise unrelated userspace memory might get
    overridden by the kernel.

    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19c0a0f3f768551fc708ebc9b2345e5dcc248d3a
Author: Paul Kot <pawlkt@gmail.com>
Date:   Tue Mar 19 12:36:49 2013 +0100

    batman-adv: bat_socket_read missing checks

    commit c00b6856fc642b234895cfabd15b289e76726430 upstream.

    Writing a icmp_packet_rr and then reading icmp_packet can lead to kernel
    memory corruption, if __user *buf is just below TASK_SIZE.

    Signed-off-by: Paul Kot <pawlkt@gmail.com>
    [sven@narfation.org: made it checkpatch clean]
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3ea0c12493c9ff38a13a89bcf08846b50c1f1c
Author: Matthew Daley <mattjd@gmail.com>
Date:   Tue Mar 19 12:36:48 2013 +0100

    x25: Handle undersized/fragmented skbs

    commit cb101ed2c3c7c0224d16953fe77bfb9d6c2cb9df upstream.

    There are multiple locations in the X.25 packet layer where a skb is
    assumed to be of at least a certain size and that all its data is
    currently available at skb->data.  These assumptions are not checked,
    hence buffer overreads may occur.  Use pskb_may_pull to check these
    minimal size assumptions and ensure that data is available at skb->data
    when necessary, as well as use skb_copy_bits where needed.

    Signed-off-by: Matthew Daley <mattjd@gmail.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andrew Hendry <andrew.hendry@gmail.com>
    Acked-by: Andrew Hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21f9f5219401be3815db41e60072a53dadf828b6
Author: Matthew Daley <mattjd@gmail.com>
Date:   Tue Mar 19 12:36:47 2013 +0100

    x25: Validate incoming call user data lengths

    commit c7fd0d48bde943e228e9c28ce971a22d6a1744c4 upstream.

    X.25 call user data is being copied in its entirety from incoming messages
    without consideration to the size of the destination buffers, leading to
    possible buffer overflows. Validate incoming call user data lengths before
    these copies are performed.

    It appears this issue was noticed some time ago, however nothing seemed to
    come of it: see http://www.spinics.net/lists/linux-x25/msg00043.html and
    commit 8db09f26f912f7c90c764806e804b558da520d4f.

    Signed-off-by: Matthew Daley <mattjd@gmail.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Tested-by: Andrew Hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d104388ff9bdb5ec76d5337cd94f9ed4bbf73fbc
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Mar 19 12:36:46 2013 +0100

    KVM: Clean up error handling during VCPU creation

    commit d780592b99d7d8a5ff905f6bacca519d4a342c76 upstream.

    So far kvm_arch_vcpu_setup is responsible for freeing the vcpu struct if
    it fails. Move this confusing resonsibility back into the hands of
    kvm_vm_ioctl_create_vcpu. Only kvm_arch_vcpu_setup of x86 is affected,
    all other archs cannot fail.

    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c7028941242372574880e513207abdbe486c3e5
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Tue Mar 26 15:31:45 2013 -0400

    Btrfs: limit the global reserve to 512mb

    commit fdf30d1c1b386e1b73116cc7e0fb14e962b763b0 upstream.

    A user reported a problem where he was getting early ENOSPC with hundreds of
    gigs of free data space and 6 gigs of free metadata space.  This is because the
    global block reserve was taking up the entire free metadata space.  This is
    ridiculous, we have infrastructure in place to throttle if we start using too
    much of the global reserve, so instead of letting it get this huge just limit it
    to 512mb so that users can still get work done.  This allowed the user to
    complete his rsync without issues.  Thanks

    Reported-and-tested-by: Stefan Priebe <s.priebe@profihost.ag>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98b3faa6da804a4cbb5aa205fac0933585d49444
Author: Vivek Gautam <gautam.vivek@samsung.com>
Date:   Thu Mar 21 12:06:48 2013 +0530

    usb: xhci: Fix TRB transfer length macro used for Event TRB.

    commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream.

    Use proper macro while extracting TRB transfer length from
    Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
    for the same, and use it instead of TRB_LEN (bits 0:16) in
    case of event TRBs.

    This patch should be backported to kernels as old as 2.6.31, that
    contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
    Bulk transfer support".  This patch will have issues applying to older
    kernels.

    Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7eff9734960f1730b0373b2635e8e055592c318
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Mar 20 05:19:24 2013 +0000

    net/irda: add missing error path release_sock call

    commit 896ee0eee6261e30c3623be931c3f621428947df upstream.

    This makes sure that release_sock is called for all error conditions in
    irda_getsockopt.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9f1f48ce20a1b923429c216669d03b5a900a8cf
Author: Bing Zhao <bzhao@marvell.com>
Date:   Fri Mar 15 18:47:07 2013 -0700

    mwifiex: cancel cmd timer and free curr_cmd in shutdown process

    commit 084c7189acb3f969c855536166042e27f5dd703f upstream.

    curr_cmd points to the command that is in processing or waiting
    for its command response from firmware. If the function shutdown
    happens to occur at this time we should cancel the cmd timer and
    put the command back to free queue.

    Tested-by: Marco Cesarano <marco@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 8cc034e4c1b7901787bbf72908bc584c055b5e09
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue Mar 26 20:30:17 2013 -0400

    vt: synchronize_rcu() under spinlock is not nice...

    commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream.

    vcs_poll_data_free() calls unregister_vt_notifier(), which calls
    atomic_notifier_chain_unregister(), which calls synchronize_rcu().
    Do it *after* we'd dropped ->f_lock.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19c85a53434ec90c1c6d6b0717e1eb37c5f2f84d
Author: Konstantin Holoborodko <klh.kernel@gmail.com>
Date:   Fri Mar 29 00:06:13 2013 +0900

    usb: ftdi_sio: Add support for Mitsubishi FX-USB-AW/-BD

    commit 482b0b5d82bd916cc0c55a2abf65bdc69023b843 upstream.

    It enhances the driver for FTDI-based USB serial adapters
    to recognize Mitsubishi Electric Corp. USB/RS422 Converters
    as FT232BM chips and support them.
    https://search.meau.com/?q=FX-USB-AW

    Signed-off-by: Konstantin Holoborodko <klh.kernel@gmail.com>
    Tested-by: Konstantin Holoborodko <klh.kernel@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 460c49749ae56b5f49454ad0ce0066f80a14c385
Author: Jan Beulich <JBeulich@suse.com>
Date:   Mon Mar 11 09:39:55 2013 +0000

    xen-blkback: fix dispatch_rw_block_io() error path

    commit 0e5e098ac22dae38f957e951b70d3cf73beff0f7 upstream.

    Commit 7708992 ("xen/blkback: Seperate the bio allocation and the bio
    submission") consolidated the pendcnt updates to just a single write,
    neglecting the fact that the error path relied on it getting set to 1
    up front (such that the decrement in __end_block_io_op() would actually
    drop the count to zero, triggering the necessary cleanup actions).

    Also remove a misleading and a stale (after said commit) comment.

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c9c0901afba44cf1353505b72e146e7f87a54b6
Author: Iestyn C. Elfick <isedev@gmail.com>
Date:   Wed Mar 20 14:02:31 2013 -0500

    b43: A fix for DMA transmission sequence errors

    commit b251412db99ccd4495ce372fec7daee27bf06923 upstream.

    Intermittently, b43 will report "Out of order TX status report on DMA ring".
    When this happens, the driver must be reset before communication can resume.
    The cause of the problem is believed to be an error in the closed-source
    firmware; however, all versions of the firmware are affected.

    This change uses the observation that the expected status is always 2 less
    than the observed value, and supplies a fake status report to skip one
    header/data pair.

    Not all devices suffer from this problem, but it can occur several times
    per second under heavy load. As each occurence kills the unmodified driver,
    this patch makes if possible for the affected devices to function. The patch
    logs only the first instance of the reset operation to prevent spamming
    the logs.

    Tested-by: Chris Vine <chris@cvine.freeserve.co.uk>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b76c1eabd474cd44937fc60a26be2b926a366e55
Author: Ming Lei <ming.lei@canonical.com>
Date:   Wed Mar 20 23:25:25 2013 +0800

    sysfs: handle failure path correctly for readdir()

    commit e5110f411d2ee35bf8d202ccca2e89c633060dca upstream.

    In case of 'if (filp->f_pos ==  0 or 1)' of sysfs_readdir(),
    the failure from filldir() isn't handled, and the reference counter
    of the sysfs_dirent object pointed by filp->private_data will be
    released without clearing filp->private_data, so use after free
    bug will be triggered later.

    This patch returns immeadiately under the situation for fixing the bug,
    and it is reasonable to return from readdir() when filldir() fails.

    Reported-by: Dave Jones <davej@redhat.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f366c8f271888f48e15cc7c0ab70f184c220c8a4
Author: Ming Lei <ming.lei@canonical.com>
Date:   Wed Mar 20 23:25:24 2013 +0800

    sysfs: fix race between readdir and lseek

    commit 991f76f837bf22c5bb07261cfd86525a0a96650c upstream.

    While readdir() is running, lseek() may set filp->f_pos as zero,
    then may leave filp->private_data pointing to one sysfs_dirent
    object without holding its reference counter, so the sysfs_dirent
    object may be used after free in next readdir().

    This patch holds inode->i_mutex to avoid the problem since
    the lock is always held in readdir path.

    Reported-by: Dave Jones <davej@redhat.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8c163a2ecea7dd6c2c9efd68b6348ef0248733
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Mar 22 15:16:29 2013 +0000

    staging: comedi: s626: fix continuous acquisition

    commit e4317ce877a31dbb9d96375391c1c4ad2210d637 upstream.

    For the s626 driver, there is a bug in the handling of asynchronous
    commands on the AI subdevice when the stop source is `TRIG_NONE`.  The
    command should run continuously until cancelled, but the interrupt
    handler stops the command running after the first scan.

    The command set-up function `s626_ai_cmd()` contains this code:

    	switch (cmd->stop_src) {
    	case TRIG_COUNT:
    		/*  data arrives as one packet */
    		devpriv->ai_sample_count = cmd->stop_arg;
    		devpriv->ai_continous = 0;
    		break;
    	case TRIG_NONE:
    		/*  continous acquisition */
    		devpriv->ai_continous = 1;
    		devpriv->ai_sample_count = 0;
    		break;
    	}

    The interrupt handler `s626_irq_handler()` contains this code:

    		if (!(devpriv->ai_continous))
    			devpriv->ai_sample_count--;
    		if (devpriv->ai_sample_count <= 0) {
    			devpriv->ai_cmd_running = 0;
    			/* ... */
    		}

    So `devpriv->ai_sample_count` is only decremented for the `TRIG_COUNT`
    case, but `devpriv->ai_cmd_running` is set to 0 (and the command
    stopped) regardless.

    Fix this in `s626_ai_cmd()` by setting `devpriv->ai_sample_count = 1`
    for the `TRIG_NONE` case.  The interrupt handler will not decrement it
    so it will remain greater than 0 and the check for stopping the
    acquisition will fail.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a0f79c84c9966f19cb44e1c37344faf30ed5e22
Author: Ming Lei <ming.lei@canonical.com>
Date:   Mon Mar 18 23:45:11 2013 +0800

    Bluetooth: Add support for Dell[QCA 0cf3:817a]

    commit ebaf5795ef57a70a042ea259448a465024e2821d upstream.

    Add support for the AR9462 chip

    T:  Bus=03 Lev=01 Prnt=01 Port=08 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=0cf3 ProdID=817a Rev= 0.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
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54f0a27d68535e728a0d7780cc809d97895ce3f9
Author: Ming Lei <ming.lei@canonical.com>
Date:   Fri Mar 15 11:00:39 2013 +0800

    Bluetooth: Add support for Dell[QCA 0cf3:0036]

    commit d66629c1325399cf080ba8b2fb086c10e5439cdd upstream.

    Add support for the AR9462 chip

    T:  Bus=03 Lev=01 Prnt=01 Port=01 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=0cf3 ProdID=0036 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d422b3c8954fa7228c4606b2af1e5c46783c566
Author: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Date:   Wed Mar 13 19:46:20 2013 -0300

    Bluetooth: Fix not closing SCO sockets in the BT_CONNECT2 state

    commit eb20ff9c91ddcb2d55c1849a87d3db85af5e88a9 upstream.

    With deferred setup for SCO, it is possible that userspace closes the
    socket when it is in the BT_CONNECT2 state, after the Connect Request is
    received but before the Accept Synchonous Connection is sent.

    If this happens the following crash was observed, when the connection is
    terminated:

    [  +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10
    [  +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16
    [  +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110
    [  +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199
    [  +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
    [  +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0
    [  +0.000000] Oops: 0002 [#1] SMP
    [  +0.000000] Modules linked in: rfcomm bnep btusb bluetooth
    [  +0.000000] CPU 0
    [  +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd #1 Bochs Bochs
    [  +0.000000] RIP: 0010:[<ffffffff810620dd>]  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
    [  +0.000000] RSP: 0018:ffff88003c3c19d8  EFLAGS: 00010002
    [  +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000
    [  +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868
    [  +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000
    [  +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002
    [  +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850
    [  +0.000000] FS:  0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
    [  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0
    [  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000)
    [  +0.000000] Stack:
    [  +0.000000]  ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868
    [  +0.000000]  ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd
    [  +0.000000]  0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a
    [  +0.000000] Call Trace:
    [  +0.000000]  [<ffffffff8101efbd>] ? kvm_clock_read+0x34/0x3b
    [  +0.000000]  [<ffffffff81007c7a>] ? paravirt_sched_clock+0x9/0xd
    [  +0.000000]  [<ffffffff81007fd4>] ? sched_clock+0x9/0xb
    [  +0.000000]  [<ffffffff8104fd7a>] ? sched_clock_local+0x12/0x75
    [  +0.000000]  [<ffffffff810632d1>] lock_acquire+0x93/0xb1
    [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
    [  +0.000000]  [<ffffffff8105f3d8>] ? lock_release_holdtime.part.22+0x4e/0x55
    [  +0.000000]  [<ffffffff814f6038>] _raw_spin_lock+0x40/0x74
    [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
    [  +0.000000]  [<ffffffff814f6936>] ? _raw_spin_unlock+0x23/0x36
    [  +0.000000]  [<ffffffffa0022339>] spin_lock+0x9/0xb [bluetooth]
    [  +0.000000]  [<ffffffffa00230cc>] sco_conn_del+0x76/0xbb [bluetooth]
    [  +0.000000]  [<ffffffffa002391d>] sco_connect_cfm+0x2da/0x2e9 [bluetooth]
    [  +0.000000]  [<ffffffffa000862a>] hci_proto_connect_cfm+0x38/0x65 [bluetooth]
    [  +0.000000]  [<ffffffffa0008d30>] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth]
    [  +0.000000]  [<ffffffffa000cd96>] hci_event_packet+0x153b/0x239d [bluetooth]
    [  +0.000000]  [<ffffffff814f68ff>] ? _raw_spin_unlock_irqrestore+0x48/0x5c
    [  +0.000000]  [<ffffffffa00025f6>] hci_rx_work+0xf3/0x2e3 [bluetooth]
    [  +0.000000]  [<ffffffff8103efed>] process_one_work+0x1dc/0x30b
    [  +0.000000]  [<ffffffff8103ef83>] ? process_one_work+0x172/0x30b
    [  +0.000000]  [<ffffffff8103e07f>] ? spin_lock_irq+0x9/0xb
    [  +0.000000]  [<ffffffff8103fc8d>] worker_thread+0x123/0x1d2
    [  +0.000000]  [<ffffffff8103fb6a>] ? manage_workers+0x240/0x240
    [  +0.000000]  [<ffffffff81044211>] kthread+0x9d/0xa5
    [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
    [  +0.000000]  [<ffffffff814f75bc>] ret_from_fork+0x7c/0xb0
    [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
    [  +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 <f0> ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00
    [  +0.000000] RIP  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
    [  +0.000000]  RSP <ffff88003c3c19d8>
    [  +0.000000] CR2: 0000000000000199
    [  +0.000000] ---[ end trace e73cd3b52352dd34 ]---

    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
    Tested-by: Frederic Dalleau <frederic.dalleau@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e260b286728445297514618aee4854d93195007a
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Mar 25 11:23:40 2013 -0400

    SUNRPC: Add barriers to ensure read ordering in rpc_wake_up_task_queue_locked

    commit 1166fde6a923c30f4351515b6a9a1efc513e7d00 upstream.

    We need to be careful when testing task->tk_waitqueue in
    rpc_wake_up_task_queue_locked, because it can be changed while we
    are holding the queue->lock.
    By adding appropriate memory barriers, we can ensure that it is safe to
    test task->tk_waitqueue for equality if the RPC_TASK_QUEUED bit is set.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 405c3ddd2026ab2376afd03e7a299ba58f12280f
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Wed Mar 13 14:59:34 2013 -0700

    kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER

    commit 522cff142d7d2f9230839c9e1f21a4d8bcc22a4a upstream.

    __ARCH_HAS_SA_RESTORER is the preferred conditional for use in 3.9 and
    later kernels, per Kees.

    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Emese Revfy <re.emese@gmail.com>
    Cc: Emese Revfy <re.emese@gmail.com>
    Cc: PaX Team <pageexec@freemail.hu>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Serge Hallyn <serge.hallyn@canonical.com>
    Cc: Julien Tinnes <jln@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c190534db77a019936d95a1826a55bf34d7ed23
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Nov 25 22:24:19 2012 -0500

    signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer

    Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
    struct sigaction declarations'.

    flush_signal_handlers() needs to know whether sigaction::sa_restorer
    is defined, not whether SA_RESTORER is defined.  Define the
    __ARCH_HAS_SA_RESTORER macro to indicate this.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
update defconfigs