Squashed commit of the following:

commit b87061d88bb223d21d7f0621e218526011460f03
Merge: 674f830 d10b95b
Author: Dan Pasanen <dan.pasanen@gmail.com>
Date:   Sat Sep 21 20:05:41 2013 -0500

    Merge remote-tracking branch 'korg/linux-3.4.y' into cm-10.2

commit 674f830709b75bb1b90a2e0200e7ec110fb574ac
Merge: 2bd4248 ed6b811
Author: Dan Pasanen <dan.pasanen@gmail.com>
Date:   Sat Sep 21 20:05:31 2013 -0500

    Merge remote-tracking branch 'caf/jb_2.6' into cm-10.2

commit 2bd4248dbaaa7a2d871c37891f1e73fa9a687612
Merge: c2bf615 0aecf16
Author: Dan Pasanen <dan.pasanen@gmail.com>
Date:   Sun Sep 22 00:33:53 2013 +0000

    Merge "apexq/expressatt: allow gpu app locking" into cm-10.2

commit c2bf615409b83956222e7461f185a95074ac57c1
Merge: 303aa39 d617ca0
Author: Shareef Ali <shareefalis@cyanogenmod.org>
Date:   Sat Sep 21 03:41:33 2013 +0000

    Merge "d2 et al.: disable OABI compat" into cm-10.2

commit 0aecf163152cdfcddfedfd1a4cf955af087a00f0
Author: David Daynard <nardholio@gmail.com>
Date:   Sun Sep 15 21:45:10 2013 -0400

    apexq/expressatt: allow gpu app locking

    - Iommu on apexq/expressatt is not broken like d2 and
      does not cause watchdog timeouts on the modem

    Change-Id: I98569b2d8e3c93be1050d43f455bbbe89c123e74

commit 303aa3925d41b239511c830179826caaec833186
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Thu Dec 15 15:44:45 2011 -0600

    AIO: Don't plug the I/O queue in do_io_submit()

    Asynchronous I/O latency to a solid-state disk greatly increased
    between the 2.6.32 and 3.0 kernels. By removing the plug from
    do_io_submit(), we observed a 34% improvement in the I/O latency.

    Unfortunately, at this level, we don't know if the request is to
    a rotating disk or not.

    Change-Id: I7101df956473ed9fd5dcff18e473dd93b688a5c1
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Cc: linux-aio@kvack.org
    Cc: Chris Mason <chris.mason@oracle.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>

commit d10b95b412369a7f1d437304db7d02d41fe33e22
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 14 06:02:37 2013 -0700

    Linux 3.4.62

commit 5e1f777d673a7d618087f093d1ca551da118d34b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 12 09:53:11 2013 -0700

    Revert "KVM: X86 emulator: fix source operand decoding for 8bit mov[zs]x instructions"

    This reverts commit 5b5b30580218eae22609989546bac6e44d0eda6e, which was
    commit 660696d1d16a71e15549ce1bf74953be1592bcd3 upstream.

    Paul Gortmaker <paul.gortmaker@windriver.com> writes:

    [this patch] introduces the following:

    arch/x86/kvm/emulate.c: In function ‘decode_operand’:
    arch/x86/kvm/emulate.c:3974:4: warning: passing argument 1 of ‘decode_register’ makes integer from pointer
    +without a cast [enabled by default]
    arch/x86/kvm/emulate.c:789:14: note: expected ‘u8’ but argument is of type ‘struct x86_emulate_ctxt *’
    arch/x86/kvm/emulate.c:3974:4: warning: passing argument 2 of ‘decode_register’ makes pointer from integer
    +without a cast [enabled by default]
    arch/x86/kvm/emulate.c:789:14: note: expected ‘long unsigned int *’ but argument is of type ‘u8’

    Based on the severity of the warnings above, I'm reasonably sure there will
    be some kind of runtime regressions due to this, but I stopped to investigate
    the warnings as soon as I saw them, before any run time testing.

    It happens because mainline v3.7-rc1~113^2~40 (dd856efafe60) does this:

    -static void *decode_register(u8 modrm_reg, unsigned long *regs,
    +static void *decode_register(struct x86_emulate_ctxt *ctxt, u8 modrm_reg,

    Since 660696d1d16a71e1 was only applied to stable 3.4, 3.8, and 3.9 -- and
    the prerequisite above is in 3.7+, the issue should be limited to 3.4.44+

    Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f37d940d1b9a0104b857fee8dd2b934cb05dcdfb
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:05 2012 -0700

    m32r: make memset() global for CONFIG_KERNEL_BZIP2=y

    commit 9a75c6e5240f7edc5955e8da5b94bde6f96070b3 upstream.

    Fix the m32r compile error:

      arch/m32r/boot/compressed/misc.c:31:14: error: static declaration of 'memset' follows non-static declaration
      make[5]: *** [arch/m32r/boot/compressed/misc.o] Error 1
      make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2

    by removing the static keyword.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    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 73efe77679cf4f7e59d20fb1e366771edb9595f5
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:04 2012 -0700

    m32r: add memcpy() for CONFIG_KERNEL_GZIP=y

    commit a8abbca6617e1caa2344d2d38d0a35f3e5928b79 upstream.

    Fix the m32r link error:

        LD      arch/m32r/boot/compressed/vmlinux
      arch/m32r/boot/compressed/misc.o: In function `zlib_updatewindow':
      misc.c:(.text+0x190): undefined reference to `memcpy'
      misc.c:(.text+0x190): relocation truncated to fit: R_M32R_26_PLTREL against undefined symbol `memcpy'
      make[5]: *** [arch/m32r/boot/compressed/vmlinux] Error 1

    by adding our own implementation of memcpy().

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    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 a44315aeee52062dea1f1f40acd084ab7fc2c8e2
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:02 2012 -0700

    m32r: consistently use "suffix-$(...)"

    commit df12aef6a19bb2d69859a94936bda0e6ccaf3327 upstream.

    Commit a556bec9955c ("m32r: fix arch/m32r/boot/compressed/Makefile")
    changed "$(suffix_y)" to "$(suffix-y)", but didn't update any location
    where "suffix_y" is set, causing:

      make[5]: *** No rule to make target `arch/m32r/boot/compressed/vmlinux.bin.', needed by `arch/m32r/boot/compressed/piggy.o'.  Stop.
      make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2
      make[3]: *** [zImage] Error 2

    Correct the other locations to fix this.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    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 0aa1fedab07204880b8d1e935cc0782b55dfae21
Author: Ying Xue <ying.xue@windriver.com>
Date:   Thu Aug 16 12:09:07 2012 +0000

    tipc: fix lockdep warning during bearer initialization

    [ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

    When the lockdep validator is enabled, it will report the below
    warning when we enable a TIPC bearer:

    [ INFO: possible irq lock inversion dependency detected ]
    ---------------------------------------------------------
    Possible interrupt unsafe locking scenario:

            CPU0                    CPU1
            ----                    ----
       lock(ptype_lock);
                                    local_irq_disable();
                                    lock(tipc_net_lock);
                                    lock(ptype_lock);
       <Interrupt>
       lock(tipc_net_lock);

      *** DEADLOCK ***

    the shortest dependencies between 2nd lock and 1st lock:
      -> (ptype_lock){+.+...} ops: 10 {
    [...]
    SOFTIRQ-ON-W at:
                          [<c1089418>] __lock_acquire+0x528/0x13e0
                          [<c108a360>] lock_acquire+0x90/0x100
                          [<c1553c38>] _raw_spin_lock+0x38/0x50
                          [<c14651ca>] dev_add_pack+0x3a/0x60
                          [<c182da75>] arp_init+0x1a/0x48
                          [<c182dce5>] inet_init+0x181/0x27e
                          [<c1001114>] do_one_initcall+0x34/0x170
                          [<c17f7329>] kernel_init+0x110/0x1b2
                          [<c155b6a2>] kernel_thread_helper+0x6/0x10
    [...]
       ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
       ... acquired at:
        [<c108a360>] lock_acquire+0x90/0x100
        [<c1553c38>] _raw_spin_lock+0x38/0x50
        [<c14651ca>] dev_add_pack+0x3a/0x60
        [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
        [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
        [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
        [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
        [<c148e802>] genl_rcv_msg+0x232/0x280
        [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
        [<c148e5bc>] genl_rcv+0x1c/0x30
        [<c148d144>] netlink_unicast+0x174/0x1f0
        [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
        [<c1456bc1>] sock_aio_write+0x161/0x170
        [<c1135a7c>] do_sync_write+0xac/0xf0
        [<c11360f6>] vfs_write+0x156/0x170
        [<c11361e2>] sys_write+0x42/0x70
        [<c155b0df>] sysenter_do_call+0x12/0x38
    [...]
    }
      -> (tipc_net_lock){+..-..} ops: 4 {
    [...]
        IN-SOFTIRQ-R at:
                         [<c108953a>] __lock_acquire+0x64a/0x13e0
                         [<c108a360>] lock_acquire+0x90/0x100
                         [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                         [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                         [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                         [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                         [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                         [<c13c43d2>] pcnet32_poll+0x292/0x780
                         [<c146b00a>] net_rx_action+0xfa/0x1e0
                         [<c103a4be>] __do_softirq+0xae/0x1e0
    [...]
    }

    >From the log, we can see three different call chains between
    CPU0 and CPU1:

    Time 0 on CPU0:

      kernel_init()->inet_init()->dev_add_pack()

    At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

    Time 1 on CPU1:

      tipc_enable_bearer()->enable_bearer()->dev_add_pack()

    At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
    wants to take ptype_lock to register TIPC protocol handler into the
    networking stack.  But the ptype_lock has been taken by dev_add_pack()
    on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
    busy looping.

    Time 2 on CPU0:

      netif_receive_skb()->recv_msg()->tipc_recv_msg()

    At time 2, an incoming TIPC packet arrives at CPU0, hence
    tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
    to hold tipc_net_lock.  At the moment, below scenario happens:

    On CPU0, below is our sequence of taking locks:

      lock(ptype_lock)->lock(tipc_net_lock)

    On CPU1, our sequence of taking locks looks like:

      lock(tipc_net_lock)->lock(ptype_lock)

    Obviously deadlock may happen in this case.

    But please note the deadlock possibly doesn't occur at all when the
    first TIPC bearer is enabled.  Before enable_bearer() -- running on
    CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
    recv_msg()) is not registered successfully via dev_add_pack(), so
    the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
    message comes to CPU0. But when the second TIPC bearer is
    registered, the deadlock can perhaps really happen.

    To fix it, we will push the work of registering TIPC protocol
    handler into workqueue context. After the change, both paths taking
    ptype_lock are always in process contexts, thus, the deadlock should
    never occur.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d60aa7fc969ffe14cac79b685aad011e66beb210
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Aug 6 17:29:19 2013 +0800

    macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

    commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

    We try to linearize part of the skb when the number of iov is greater than
    MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
    one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
    network.

    Solve this problem by calculate the pages needed for iov before trying to do
    zerocopy and switch to use copy instead of zerocopy if it needs more than
    MAX_SKB_FRAGS.

    This is done through introducing a new helper to count the pages for iov, and
    call uarg->callback() manually when switching from zerocopy to copy to notify
    vhost.

    We can do further optimization on top.

    This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
    (macvtap: zerocopy: validate vectors before building skb).

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 334e23c6f2c893985cc011fbd9a26f2960ec1a97
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Aug 6 17:29:18 2013 +0800

    vhost: zerocopy: poll vq in zerocopy callback

    commit c70aa540c7a9f67add11ad3161096fb95233aa2e upstream.

    We add used and signal guest in worker thread but did not poll the virtqueue
    during the zero copy callback. This may lead the missing of adding and
    signalling during zerocopy. Solve this by polling the virtqueue and let it
    wakeup the worker during callback.

    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d22586ffdda8938a66e198acff0f2ea64d7ce62e
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Tue Sep 3 19:29:12 2013 +0200

    net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv

    [ Upstream commit 3a1c756590633c0e86df606e5c618c190926a0df ]

    In tcp_v6_do_rcv() code, when processing pkt options, we soley work
    on our skb clone opt_skb that we've created earlier before entering
    tcp_rcv_established() on our way. However, only in condition ...

      if (np->rxopt.bits.rxtclass)
        np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));

    ... we work on skb itself. As we extract every other information out
    of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
    already be released by tcp_rcv_established() earlier on. When we try
    to access it in ipv6_hdr(), we will dereference freed skb.

    [ Bug added by commit 4c507d2897bd9b ("net: implement IP_RECVTOS for
      IP_PKTOPTIONS") ]

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8708ea2b682963ce30dfd638771e7e4022094a90
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Aug 30 11:18:45 2013 +0200

    ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

    [ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

    RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
    unreachable) messages:
            5 - Source address failed ingress/egress policy
    	6 - Reject route to destination

    Now they are treated as protocol error and icmpv6_err_convert() converts them
    to EPROTO.

    RFC 4443 says:
    	"Codes 5 and 6 are more informative subsets of code 1."

    Treat codes 5 and 6 as code 1 (EACCES)

    Btw, connect() returning -EPROTO confuses firefox, so that fallback to
    other/IPv4 addresses does not work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=910773

    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-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 98fadc18d23f40203ff154d0220692834e0de8f1
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 29 23:55:05 2013 +0200

    net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

    [ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

    While looking into MLDv1/v2 code, I noticed that bridging code does
    not convert it's max delay into jiffies for MLDv2 messages as we do
    in core IPv6' multicast code.

    RFC3810, 5.1.3. Maximum Response Code says:

      The Maximum Response Code field specifies the maximum time allowed
      before sending a responding Report. The actual time allowed, called
      the Maximum Response Delay, is represented in units of milliseconds,
      and is derived from the Maximum Response Code as follows: [...]

    As we update timers that work with jiffies, we need to convert it.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Linus Lüssing <linus.luessing@web.de>
    Cc: 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 cce0727ab07058c745d1a104d84c4d0e3a100ef9
Author: Thomas Graf <tgraf@suug.ch>
Date:   Tue Sep 3 13:37:01 2013 +0200

    ipv6: Don't depend on per socket memory for neighbour discovery messages

    [ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

    Allocating skbs when sending out neighbour discovery messages
    currently uses sock_alloc_send_skb() based on a per net namespace
    socket and thus share a socket wmem buffer space.

    If a netdevice is temporarily unable to transmit due to carrier
    loss or for other reasons, the queued up ndisc messages will cosnume
    all of the wmem space and will thus prevent from any more skbs to
    be allocated even for netdevices that are able to transmit packets.

    The number of neighbour discovery messages sent is very limited,
    use of alloc_skb() bypasses the socket wmem buffer size enforcement
    while the manual call to skb_set_owner_w() maintains the socket
    reference needed for the IPv6 output path.

    This patch has orginally been posted by Eric Dumazet in a modified
    form.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Acked-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 055c396300ee15d990777841278ba94d2bc7868a
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:30:07 2013 +0200

    ipv6: drop packets with multiple fragmentation headers

    [ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

    It is not allowed for an ipv6 packet to contain multiple fragmentation
    headers. So discard packets which were already reassembled by
    fragmentation logic and send back a parameter problem icmp.

    The updates for RFC 6980 will come in later, I have to do a bit more
    research here.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    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 f4cb837d1bdb6e1592523ce76c3f45188d120b4e
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:02:27 2013 +0200

    ipv6: remove max_addresses check from ipv6_create_tempaddr

    [ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

    Because of the max_addresses check attackers were able to disable privacy
    extensions on an interface by creating enough autoconfigured addresses:

    <http://seclists.org/oss-sec/2012/q4/292>

    But the check is not actually needed: max_addresses protects the
    kernel to install too many ipv6 addresses on an interface and guards
    addrconf_prefix_rcv to install further addresses as soon as this limit
    is reached. We only generate temporary addresses in direct response of
    a new address showing up. As soon as we filled up the maximum number of
    addresses of an interface, we stop installing more addresses and thus
    also stop generating more temp addresses.

    Even if the attacker tries to generate a lot of temporary addresses
    by announcing a prefix and removing it again (lifetime == 0) we won't
    install more temp addresses, because the temporary addresses do count
    to the maximum number of addresses, thus we would stop installing new
    autoconfigured addresses when the limit is reached.

    This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
    possible).

    Thanks to Ding Tianhong to bring this topic up again.

    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Ding Tianhong <dingtianhong@huawei.com>
    Cc: George Kargiotakis <kargig@void.gr>
    Cc: P J P <ppandit@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62d5a1d2a8a7c247c1f2dcd87b1e8c533b03017b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 15:52:57 2013 +0300

    tun: signedness bug in tun_get_user()

    [ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

    The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
    not totally correct.  Because "len" and "sizeof()" are size_t type, that
    means they are never less than zero.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abdf975d2095b3f41939ec0e2259af5d485f2889
Author: Dave Jones <davej@redhat.com>
Date:   Fri Aug 9 11:16:34 2013 -0700

    8139cp: Fix skb leak in rx_status_loop failure path.

    [ Upstream commit d06f5187469eee1b2932c02fd093d113cfc60d5e ]

    Introduced in cf3c4c03060b688cbc389ebc5065ebcce5653e96
    ("8139cp: Add dma_mapping_error checking")

    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f1322071c591867b963eac2c42643b0dce29bca
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Aug 7 02:34:31 2013 +0200

    ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

    [ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

    In case a subtree did not match we currently stop backtracking and return
    NULL (root table from fib_lookup). This could yield in invalid routing
    table lookups when using subtrees.

    Instead continue to backtrack until a valid subtree or node is found
    and return this match.

    Also remove unneeded NULL check.

    Reported-by: Teco Boot <teco@inf-net.nl>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Cc: David Lamparter <equinox@diac24.net>
    Cc: <boutier@pps.univ-paris-diderot.fr>
    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 6b7f7bf782f38216c7584a21e4189ff637056e56
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 20:05:12 2013 -0700

    tcp: cubic: fix bug in bictcp_acked()

    [ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

    While investigating about strange increase of retransmit rates
    on hosts ~24 days after boot, Van found hystart was disabled
    if ca->epoch_start was 0, as following condition is true
    when tcp_time_stamp high order bit is set.

    (s32)(tcp_time_stamp - ca->epoch_start) < HZ

    Quoting Van :

     At initialization & after every loss ca->epoch_start is set to zero so
     I believe that the above line will turn off hystart as soon as the 2^31
     bit is set in tcp_time_stamp & hystart will stay off for 24 days.
     I think we've observed that cubic's restart is too aggressive without
     hystart so this might account for the higher drop rate we observe.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: 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 a0dfebe913d760806692764ef33c2c9b85d60025
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 17:10:15 2013 -0700

    tcp: cubic: fix overflow error in bictcp_update()

    [ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

    commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
    overflow error in bictcp_update() in following code :

    /* change the unit from HZ to bictcp_HZ */
    t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
          ca->epoch_start) << BICTCP_HZ) / HZ;

    Because msecs_to_jiffies() being unsigned long, compiler does
    implicit type promotion.

    We really want to constrain (tcp_time_stamp - ca->epoch_start)
    to a signed 32bit value, or else 't' has unexpected high values.

    This bugs triggers an increase of retransmit rates ~24 days after
    boot [1], as the high order bit of tcp_time_stamp flips.

    [1] for hosts with HZ=1000

    Big thanks to Van Jacobson for spotting this problem.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    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 07d5c260fe3ff9d13277902ec6d0434b0fcd0e95
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 11:18:49 2013 -0700

    fib_trie: remove potential out of bound access

    [ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

    AddressSanitizer [1] dynamic checker pointed a potential
    out of bound access in leaf_walk_rcu()

    We could allocate one more slot in tnode_new() to leave the prefetch()
    in-place but it looks not worth the pain.

    Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

    [1] :
    https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71244e7b9f89ee8825f265a821475a553589a726
Author: Veaceslav Falico <vfalico@redhat.com>
Date:   Fri Aug 2 19:07:39 2013 +0200

    bonding: modify only neigh_parms owned by us

    [ Upstream commit 9918d5bf329d0dc5bb2d9d293bcb772bdb626e65 ]

    Otherwise, on neighbour creation, bond_neigh_init() will be called with a
    foreign netdev.

    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 3b5c0012686fac17b4fac1c11fba65f45bbdbff8
Author: Veaceslav Falico <vfalico@redhat.com>
Date:   Fri Aug 2 19:07:38 2013 +0200

    neighbour: populate neigh_parms on alloc before calling ndo_neigh_setup

    [ Upstream commit 63134803a6369dcf7dddf7f0d5e37b9566b308d2 ]

    dev->ndo_neigh_setup() might need some of the values of neigh_parms, so
    populate them before calling it.

    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 dbe3f7527fa31ccdb0aff8635dc03124f487a1f4
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Fri Aug 2 18:36:40 2013 +0400

    net: check net.core.somaxconn sysctl values

    [ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

    It's possible to assign an invalid value to the net.core.somaxconn
    sysctl variable, because there is no checks at all.

    The sk_max_ack_backlog field of the sock structure is defined as
    unsigned short. Therefore, the backlog argument in inet_listen()
    shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
    is truncated to the somaxconn value. So, the somaxconn value shouldn't
    exceed 65535 (USHRT_MAX).
    Also, negative values of somaxconn are meaningless.

    before:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    net.core.somaxconn = 65536
    $ sysctl -w net.core.somaxconn=-100
    net.core.somaxconn = -100

    after:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    error: "Invalid argument" setting key "net.core.somaxconn"
    $ sysctl -w net.core.somaxconn=-100
    error: "Invalid argument" setting key "net.core.somaxconn"

    Based on a prior patch from Changli Gao.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Reported-by: Changli Gao <xiaosuo@gmail.com>
    Suggested-by: Eric Dumazet <edumazet@google.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 8da9d4fa4361a160c0cfc8b5e8b6111c89f1f2ef
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu Aug 1 22:32:07 2013 -0700

    htb: fix sign extension bug

    [ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

    When userspace passes a large priority value
    the assignment of the unsigned value hopt->prio
    to  signed int cl->prio causes cl->prio to become negative and the
    comparison is with TC_HTB_NUMPRIO is always false.

    The result is that HTB crashes by referencing outside
    the array when processing packets. With this patch the large value
    wraps around like other values outside the normal range.

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

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    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 e4db9b407f482a4732979423082169029b23d2f5
Author: David Daynard <nardholio@gmail.com>
Date:   Fri Sep 13 17:52:35 2013 -0400

    prima 3.2.3.172

    Change-Id: Ic8e7d319f76430ad5b807eb2a5264d2c66c86359

commit d617ca010a10b2c7ca84e914a1042c363993ec06
Author: David Daynard <nardholio@gmail.com>
Date:   Fri Sep 13 15:28:20 2013 -0400

    d2 et al.: disable OABI compat

    Commit fefc65c201fc50bd4f22602292bbf48c8df23450 removed the requirement
    for OABI compatibility back in April due to TLB crashes, but we still
    have it on.

    There is no reason I can think of to leave this on.

    Change-Id: Idec3a3f4a931db601ad469e892b30eb18be4deed

commit 58055a005855e4befb1d952aadba98acd78da354
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 7 21:58:39 2013 -0700

    Linux 3.4.61

commit d3ba21877b9488abffd4528aa4b316ec5af27ea3
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Aug 5 17:55:01 2013 -0700

    SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal

    commit 35dc248383bbab0a7203fca4d722875bc81ef091 upstream.

    There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
    leads to one process writing data into the address space of some other
    random unrelated process if the ioctl is interrupted by a signal.
    What happens is the following:

     - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
       underlying SCSI command will transfer data from the SCSI device to
       the buffer provided in the ioctl)

     - Before the command finishes, a signal is sent to the process waiting
       in the ioctl.  This will end up waking up the sg_ioctl() code:

    		result = wait_event_interruptible(sfp->read_wait,
    			(srp_done(sfp, srp) || sdp->detached));

       but neither srp_done() nor sdp->detached is true, so we end up just
       setting srp->orphan and returning to userspace:

    		srp->orphan = 1;
    		write_unlock_irq(&sfp->rq_list_lock);
    		return result;	/* -ERESTARTSYS because signal hit process */

       At this point the original process is done with the ioctl and
       blithely goes ahead handling the signal, reissuing the ioctl, etc.

     - Eventually, the SCSI command issued by the first ioctl finishes and
       ends up in sg_rq_end_io().  At the end of that function, we run through:

    	write_lock_irqsave(&sfp->rq_list_lock, iflags);
    	if (unlikely(srp->orphan)) {
    		if (sfp->keep_orphan)
    			srp->sg_io_owned = 0;
    		else
    			done = 0;
    	}
    	srp->done = done;
    	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

    	if (likely(done)) {
    		/* Now wake up any sg_read() that is waiting for this
    		 * packet.
    		 */
    		wake_up_interruptible(&sfp->read_wait);
    		kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN);
    		kref_put(&sfp->f_ref, sg_remove_sfp);
    	} else {
    		INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext);
    		schedule_work(&srp->ew.work);
    	}

       Since srp->orphan *is* set, we set done to 0 (assuming the
       userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
       ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
       to run in a workqueue.

     - In workqueue context we go through sg_rq_end_io_usercontext() ->
       sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
       bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().

       The key point here is that we are doing copy_to_user() on a
       workqueue -- that is, we're on a kernel thread with current->mm
       equal to whatever random previous user process was scheduled before
       this kernel thread.  So we end up copying whatever data the SCSI
       command returned to the virtual address of the buffer passed into
       the original ioctl, but it's quite likely we do this copying into a
       different address space!

    As suggested by James Bottomley <James.Bottomley@hansenpartnership.com>,
    add a check for current->mm (which is NULL if we're on a kernel thread
    without a real userspace address space) in bio_uncopy_user(), and skip
    the copy if we're on a kernel thread.

    There's no reason that I can think of for any caller of bio_uncopy_user()
    to want to do copying on a kernel thread with a random active userspace
    address space.

    Huge thanks to Costa Sapuntzakis <costa@purestorage.com> for the
    original pointer to this bug in the sg code.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Tested-by: David Milburn <dmilburn@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [lizf: backported to 3.4:
     - Use __bio_for_each_segment() instead of bio_for_each_segment_all()]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e51c435e8f955faeb93c8a10f71d7ebf43d887db
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 24 16:15:08 2013 -0700

    target: Fix trailing ASCII space usage in INQUIRY vendor+model

    commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream.

    This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
    spaces for INQUIRY vendor + model fields following SPC-4 text:

      "ASCII data fields described as being left-aligned shall have any
       unused bytes at the end of the field (i.e., highest offset) and
       the unused bytes shall be filled with ASCII space characters (20h)."

    This addresses a problem with Falconstor NSS multipathing.

    Reported-by: Tomas Molota <tomas.molota@lightstorm.sk>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f661fbf82b3751be0875ed0993d4c29f8268186
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

    commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

    The ECDT of ASUSTEK L4R doesn't provide correct command and data
    I/O ports.  The DSDT provides the correct information instead.

    For this reason, add this machine to quirk list for ECDT validation
    and use the EC information from the DSDT.

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    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 32cdf9033d757224ec8edc7d15a2206fe5975f5b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Aug 21 10:18:19 2013 +0200

    iwl4965: fix rfkill set state regression

    commit b2fcc0aee58a3435566dd6d8501a0b355552f28b upstream.

    My current 3.11 fix:

    commit 788f7a56fce1bcb2067b62b851a086fca48a0056
    Author: Stanislaw Gruszka <sgruszka@redhat.com>
    Date:   Thu Aug 1 12:07:55 2013 +0200

        iwl4965: reset firmware after rfkill off

    broke rfkill notification to user-space . I missed that bug, because
    I compiled without CONFIG_RFKILL, sorry about that.

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 837049ab21626553f6d84062cde74e38d4b7b0bd
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date:   Fri Aug 16 21:39:40 2013 +0200

    ath9k_htc: Restore skb headroom when returning skb to mac80211

    commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 upstream.

    ath9k_htc adds padding between the 802.11 header and the payload during
    TX by moving the header. When handing the frame back to mac80211 for TX
    status handling the header is not moved back into its original position.
    This can result in a too small skb headroom when entering ath9k_htc
    again (due to a soft retransmission for example) causing an
    skb_under_panic oops.

    Fix this by moving the 802.11 header back into its original position
    before returning the frame to mac80211 as other drivers like rt2x00
    or ath5k do.

    Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52b331e9991f5639e8888349eccc02dd2986b51c
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 28 13:35:13 2013 -0400

    SUNRPC: Fix memory corruption issue on 32-bit highmem systems

    commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c upstream.

    Some architectures, such as ARM-32 do not return the same base address
    when you call kmap_atomic() twice on the same page.
    This causes problems for the memmove() call in the XDR helper routine
    "_shift_data_right_pages()", since it defeats the detection of
    overlapping memory ranges, and has been seen to corrupt memory.

    The fix is to distinguish between the case where we're doing an
    inter-page copy or not. In the former case of we know that the memory
    ranges cannot possibly overlap, so we can additionally micro-optimise
    by replacing memmove() with memcpy().

    Reported-by: Mark Young <MYoung@nvidia.com>
    Reported-by: Matt Craighead <mcraighead@nvidia.com>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Matt Craighead <mcraighead@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5817e3c7a152e2febbb342a807487e739395a973
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri Aug 23 23:50:23 2013 +0300

    drm/i915: ivb: fix edp voltage swing reg val

    commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream.

    Fix the typo introduced in

    commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85
    Author: Keith Packard <keithp@keithp.com>
    Date:   Wed Nov 16 16:26:07 2011 -0800

        drm/i915: Hook up Ivybridge eDP

    This fixes eDP link-training failures and cases where all voltage swing
    /pre-emphasis levels were tried and failed during clock recovery and -
    as a fallback - we go on to do channel equalization with the last voltage
    swing/pre-emphasis level which will succeed. Both issues can lead to a
    blank screen.

    v2:
    - improve commit message

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880
    Tested-by: Jeremy Moles <cubicool@gmail.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73bc40b87e7e61dea9e06576f7e1c5eaf49abe31
Author: Jakob Bornecrantz <jakob@vmware.com>
Date:   Thu Aug 29 02:32:53 2013 +0200

    drm/vmwgfx: Split GMR2_REMAP commands if they are to large

    commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f upstream.

    This fixes the piglit test texturing/max-texture-size
    causing the VM to die due to a too large SVGA command.

    Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
    Reviewed-by: Biran Paul <brianp@vmware.com>
    Reviewed-by: Zack Rusin <zackr@vmware.com>
    Signed-off-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e99f322b52642004e9949bedf70bb12f12e3a17
Author: Russ Anderson <rja@sgi.com>
Date:   Wed Aug 28 16:35:18 2013 -0700

    drivers/base/memory.c: fix show_mem_removable() to handle missing sections

    commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream.

    "cat /sys/devices/system/memory/memory*/removable" crashed the system.

    The problem is that show_mem_removable() is passing a
    bad pfn to is_mem_section_removable(), which causes

        if (!node_online(page_to_nid(page)))

    to blow up.  Why is it passing in a bad pfn?

    The reason is that show_mem_removable() will loop sections_per_block
    times.  sections_per_block is 16, but mem->section_count is 8,
    indicating holes in this memory block.  Checking that the memory section
    is present before checking to see if the memory section is removable
    fixes the problem.

       harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
       0
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       BUG: unable to handle kernel paging request at ffffea00c3200000
       IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
       PGD 83ffd4067 PUD 37bdfce067 PMD 0
       Oops: 0000 [#1] SMP
       Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
       CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
       Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
       task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
       RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
       RSP: 0018:ffff880820023df8  EFLAGS: 00010287
       RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
       RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
       RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
       R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
       R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
       FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
       Call Trace:
         show_mem_removable+0x41/0x70
         dev_attr_show+0x2a/0x60
         sysfs_read_file+0xf7/0x1c0
         vfs_read+0xc8/0x130
         SyS_read+0x5d/0xa0
         system_call_fastpath+0x16/0x1b

    Signed-off-by: Russ Anderson <rja@sgi.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff289c1fa9e4ca50d0ec0197678fa565f7b65d1b
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Mon Oct 8 22:06:30 2012 +0200

    regmap: silence GCC warning

    commit a8f28cfad8cd44d7c34b166d0e5ace1125dbee1f upstream.

    Building regmap.o triggers this GCC warning:
        drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
        drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]

    Long story short: Jakub Jelinek pointed out that there is a type
    mismatch between 'num' in regmap_volatile_range() and 'val_count' in
    regmap_raw_read(). And indeed, converting 'num' to the type of
    'val_count' (ie, size_t) makes this warning go away.

    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ad23b795892c3f128cb05de5ee6d5ae5c422c28
Author: Eugene Surovegin <ebs@ebshome.net>
Date:   Mon Aug 26 11:53:32 2013 -0700

    powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

    commit d220980b701d838560a70de691b53be007e99e78 upstream.

    This solves a problem observed in kexec'ed kernel where 200ms timeout is
    too short and bootconsole fails to initialize. Console did eventually
    become workable but much later into the boot process.

    Observed timeout was around 260ms, but I decided to make it a little bigger
    for more reliability.

    This has been tested on Power7 machine with Petitboot as a primary
    bootloader and PowerNV firmware.

    Signed-off-by: Eugene Surovegin <surovegin@google.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a72233b3de7a35cd106db00f46c38960f9698f4
Author: Paul Mackerras <paulus@samba.org>
Date:   Tue Aug 27 16:07:49 2013 +1000

    powerpc: Work around gcc miscompilation of __pa() on 64-bit

    commit bdbc29c19b2633b1d9c52638fb732bcde7a2031a upstream.

    On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
    gcc as something like:

            addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
            addi 3,3,.LANCHOR1+4611686018427387904@toc@l

    This ends up effectively ignoring the offset, since its bottom 32 bits
    are zero, and means that the result of __pa() still has 0xC in the top
    nibble.  This happens with gcc 4.8.1, at least.

    To work around this, for 64-bit we make __pa() use an AND operator,
    and for symmetry, we make __va() use an OR operator.  Using an AND
    operator rather than a subtraction ends up with slightly shorter code
    since it can be done with a single clrldi instruction, whereas it
    takes three instructions to form the constant (-PAGE_OFFSET) and add
    it on.  (Note that MEMORY_START is always 0 on 64-bit.)

    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa5189165d9897c84b43d762618ee8924c5f9c9e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 27 12:03:01 2013 +0200

    ALSA: opti9xx: Fix conflicting driver object name

    commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.

    The recent commit to delay the release of kobject triggered NULL
    dereferences of opti9xx drivers.  The cause is that all
    snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
    register the PnP card driver with the very same name, and also
    snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
    the same name, too.  When these drivers are built in, quick
    "register-release-and-re-register" actions occur, and this results in
    Oops because of the same name is assigned to the kobject.

    The fix is simply to assign individual names.  As a bonus, by using
    KBUILD_MODNAME, the patch reduces more lines than it adds.

    The fix is based on the suggestion by Russell King.

    Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e446ef9608a07af0cf07aa887ddf37224fd345d8
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Thu Aug 15 15:36:49 2013 -0500

    jfs: fix readdir cookie incompatibility with NFSv4

    commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 upstream.

    NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..),
    but jfs allows a value of 2 for a non-special entry. This incompatibility
    can result in the nfs client reporting a readdir loop.

    This patch doesn't change the value stored internally, but adds one to
    the value exposed to the iterate method.

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/ctx->pos/filp->f_pos/]
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed6b811906380e3aa833d444419f520eb4fa9f42
Merge: 3a0d33a 5294869
Author: Linux Build Service Account <lnxbuild@localhost>
Date:   Tue Sep 3 07:31:33 2013 -0700

    Merge "ALSA: usb-audio: Fix the mixer control range limiting issue"

commit 5294869da9984f2687d04a732aade60febc19f5d
Author: Deepa Madiregama <dmadireg@codeaurora.org>
Date:   Wed Aug 21 17:54:08 2013 +0530

    ALSA: usb-audio: Fix the mixer control range limiting issue

    - mixer_ctl_set() function is limiting the volume level
      to particular range. This results in incorrect initial
      volume setting for that device.
    - In USB mixer while calculating the dBmin/dBmax values
      resolution factor is hardcoded to 256 which results in
      populating the wrong values for dBmin/dBmax.
    - Fix is to use appropriate resolution factor while
      calculating the dBmin/dBmax values.

    CRs-Fixed: 515012
    Change-Id: I502355af66f850bb65380c27333c3341fa43a947
    Signed-off-by: Deepa Madiregama <dmadireg@codeaurora.org>

commit 3a0d33a00eb63e593a1060596373f660e996ca93
Merge: c4f6d25 9ea4077
Author: Linux Build Service Account <lnxbuild@localhost>
Date:   Tue Sep 3 00:52:57 2013 -0700

    Merge "ASoC: wcd9304: Fix dce and sta wait time"

commit c4f6d25508b00dddbd37e265e20def16ee6b1de6
Merge: 25092d5 405eb4e
Author: Linux Build Service Account <lnxbuild@localhost>
Date:   Mon Sep 2 07:59:15 2013 -0700

    Merge "msm: kgsl: use kgsl_mmu_device_setstate() whenever the gpu is idle"

commit 25092d569bfdaef8c8206cff1029ce749fb3acd7
Merge: b07d749 2bbb1ab
Author: Linux Build Service Account <lnxbuild@localhost>
Date:   Mon Sep 2 06:29:51 2013 -0700

    Merge "msm: kgsl: use the same logic in adreno_idle and adreno_isidle"

commit 405eb4e6b0d66c805a01f1a1ec82b460fb606ee6
Author: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
Date:   Thu Aug 1 15:18:02 2013 -0600

    msm: kgsl: use kgsl_mmu_device_setstate() whenever the gpu is idle

    We really don't want new GPU commands or events to be generated
    just to manage the iommu while we are idle.

    Change-Id: I2e8740bee8c25c93bddc51a90a3370d151aaf558
    Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
    (cherry picked from commit 1a3279ee70f72d67c5b259573096a9953257a9b5)
    Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>

commit b07d74912d01407920588c93c3be6fe1086afc46
Merge: 3815648 d880c96
Author: Linux Build Service Account <lnxbuild@localhost>
Date:   Mon Sep 2 02:40:35 2013 -0700

    Merge "hwmon: qpnp-adc-scale: Fix batt_therm mapping table"

commit 9ea40776e40b6376644c24fa112f501fd2f23a12
Author: Simmi Pateriya <simmip@codeaurora.org>
Date:   Fri Aug 16 15:53:01 2013 +0530

    ASoC: wcd9304: Fix dce and sta wait time

    Apply correct dce and sta wait time based on calculation
    rather than using default values.

    CRs-Fixed: 521904
    Change-Id: I15578c8ca5ba606af3d7ded85014c178ffc1effe
    Signed-off-by: Simmi Pateriya <simmip@codeaurora.org>

commit d880c962244e39a4f51406c3154c5dd65f596e3a
Author: Siddartha Mohanadoss <smohanad@codeaurora.org>
Date:   Fri Aug 23 09:40:44 2013 -0700

    hwmon: qpnp-adc-scale: Fix batt_therm mapping table

    Mapping table for batt_therm used for converting voltage
    to temperature is incorrect after 65degC. Fix the voltage
    to temperature mapping for values after 65degC.

    Change-Id: Ib8534a2be3b66f61b4edbe8f283cfee9f873af81
    Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>

commit 2bbb1ab042a260a6fdce520f881bbf967095a6a6
Author: Jeremy Gebben <jgebben@codeaurora.org>
Date:   Tue Jul 9 08:22:15 2013 -0600

    msm: kgsl: use the same logic in adreno_idle and adreno_isidle

    These two functions need to agree on the meaning of "idle",
    so that calling adreno_isidle() right after an adreno_idle()
    will always return true.

    Change-Id: I7cddf73773186c3ec8b56c111affacac3b07fcc7
    Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
    (cherry picked from commit 5365240cf0abf2d799dd849abca0dc5b46d4b784)
    Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>

    Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>