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>