commit 80e7980effb5cd929c01380b938013cb93932fe0
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu May 29 15:47:24 2014 +0200

    Linux 3.12.21

commit ac993cf25a957b332864e3200644b50e179826fc
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Apr 3 09:28:10 2014 -0700

    net-gro: reset skb->truesize in napi_reuse_skb()
    
    [ Upstream commit e33d0ba8047b049c9262fdb1fcafb93cb52ceceb ]
    
    Recycling skb always had been very tough...
    
    This time it appears GRO layer can accumulate skb->truesize
    adjustments made by drivers when they attach a fragment to skb.
    
    skb_gro_receive() can only subtract from skb->truesize the used part
    of a fragment.
    
    I spotted this problem seeing TcpExtPruneCalled and
    TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where
    TCP receive window should be sized properly to accept traffic coming
    from a driver not overshooting skb->truesize.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ee08bba5f0f2c32f12a465542ad4b6a42c4a1417
Author: Li RongQing <roy.qing.li@gmail.com>
Date:   Thu May 22 16:36:55 2014 +0800

    ipv4: initialise the itag variable in __mkroute_input
    
    [ Upstream commit fbdc0ad095c0a299e9abf5d8ac8f58374951149a ]
    
    the value of itag is a random value from stack, and may not be initiated by
    fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID
    is not set
    
    This will make the cached dst uncertainty
    
    Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
    Acked-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9b60fabbe9b3577f82c8b9519c3cb351763b7d89
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Mon May 19 11:36:56 2014 +0200

    ip_tunnel: Initialize the fallback device properly
    
    [ Upstream commit 78ff4be45a4c51d8fb21ad92e4fabb467c6c3eeb ]
    
    We need to initialize the fallback device to have a correct mtu
    set on this device. Otherwise the mtu is set to null and the device
    is unusable.
    
    Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
    Cc: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fa59cdc603bfe56ab060084edbf3cab30f1ef7a7
Author: Antonio Quartulli <antonio@open-mesh.com>
Date:   Fri May 2 01:35:13 2014 +0200

    batman-adv: increase orig refcount when storing ref in gw_node
    
    [ Upstream commit 377fe0f968b30a1a714fab53a908061914f30e26 ]
    
    A pointer to the orig_node representing a bat-gateway is
    stored in the gw_node->orig_node member, but the refcount
    for such orig_node is never increased.
    This leads to memory faults when gw_node->orig_node is accessed
    and the originator has already been freed.
    
    Fix this by increasing the refcount on gw_node creation
    and decreasing it on gw_node free.
    
    Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2413d40d59007671d3cd3121e3b0248260e34f3e
Author: Cong Wang <cwang@twopensource.com>
Date:   Mon May 12 15:11:20 2014 -0700

    rtnetlink: wait for unregistering devices in rtnl_link_unregister()
    
    [ Upstream commit 200b916f3575bdf11609cb447661b8d5957b0bbf ]
    
    From: Cong Wang <cwang@twopensource.com>
    
    commit 50624c934db18ab90 (net: Delay default_device_exit_batch until no
    devices are unregistering) introduced rtnl_lock_unregistering() for
    default_device_exit_batch(). Same race could happen we when rmmod a driver
    which calls rtnl_link_unregister() as we call dev->destructor without rtnl
    lock.
    
    For long term, I think we should clean up the mess of netdev_run_todo()
    and net namespce exit code.
    
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 166c6b578bc07449529aa40ba524c694c2fd1623
Author: Susant Sahani <susant@redhat.com>
Date:   Sat May 10 00:11:32 2014 +0530

    ip6_tunnel: fix potential NULL pointer dereference
    
    [ Upstream commit c8965932a2e3b70197ec02c6741c29460279e2a8 ]
    
    The function ip6_tnl_validate assumes that the rtnl
    attribute IFLA_IPTUN_PROTO always be filled . If this
    attribute is not filled by  the userspace application
    kernel get crashed with NULL pointer dereference. This
    patch fixes the potential kernel crash when
    IFLA_IPTUN_PROTO is missing .
    
    Signed-off-by: Susant Sahani <susant@redhat.com>
    Acked-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ce37c23f8c394e6bd271557044cbbdd0d2f7b9c9
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Fri May 9 11:11:39 2014 +0200

    sfc: fix calling of free_irq with already free vector
    
    [ Upstream commit 1c3639005f48492e5f2d965779efd814e80f8b15 ]
    
    If the sfc driver is in legacy interrupt mode (either explicitly by
    using interrupt_mode module param or by falling back to it) it will
    hit a warning at kernel/irq/manage.c because it will try to free an irq
    which wasn't allocated by it in the first place because the MSI(X) irqs are
    zero and it'll try to free them unconditionally. So fix it by checking if
    we're in legacy mode and freeing the appropriate irqs.
    
    CC: Zenghui Shi <zshi@redhat.com>
    CC: Ben Hutchings <ben@decadent.org.uk>
    CC: <linux-net-drivers@solarflare.com>
    CC: Shradha Shah <sshah@solarflare.com>
    CC: David S. Miller <davem@davemloft.net>
    
    Fixes: 1899c111a535 ("sfc: Fix IRQ cleanup in case of a probe failure")
    Reported-by: Zenghui Shi <zshi@redhat.com>
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Acked-by: Shradha Shah <sshah@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 951c8657d8c4bb80afa304e4f506cdcf40fc1b8f
Author: Peter Christensen <pch@ordbogen.com>
Date:   Thu May 8 11:15:37 2014 +0200

    macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces.
    
    [ Upstream commit bbeb0eadcf9fe74fb2b9b1a6fea82cd538b1e556 ]
    
    Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
    overflow on the underlying interface.
    
    Attempting the set IFF_ALLMULTI on the underlying interface would cause an
    error and the log message:
    
    "allmulti touches root, set allmulti failed."
    
    Signed-off-by: Peter Christensen <pch@ordbogen.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5cc338cf5f3fdf1758240b50f7403b6c9e17e1a6
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri May 9 14:45:00 2014 +0200

    net: cdc_mbim: handle unaccelerated VLAN tagged frames
    
    [ Upstream commit 6b5eeb7f874b689403e52a646e485d0191ab9507 ]
    
    This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on
    a bogus assumption that all tagged frames will use the acceleration API
    because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames
    tagged in userspace using packet sockets. Such frames will erroneously
    be considered as untagged and silently dropped based on not being IP.
    
    Fix by falling back to looking into the ethernet header for a tag if no
    accelerated tag was found.
    
    Fixes: a82c7ce5bc5b ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID")
    Cc: Greg Suarez <gsuarez@smithmicro.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d4e90595f9f3c66c88af853f2a08a103280126fc
Author: Sergey Popovich <popovich_sergei@mail.ru>
Date:   Tue May 6 18:23:08 2014 +0300

    ipv4: fib_semantics: increment fib_info_cnt after fib_info allocation
    
    [ Upstream commit aeefa1ecfc799b0ea2c4979617f14cecd5cccbfd ]
    
    Increment fib_info_cnt in fib_create_info() right after successfuly
    alllocating fib_info structure, overwise fib_metrics allocation failure
    leads to fib_info_cnt incorrectly decremented in free_fib_info(), called
    on error path from fib_create_info().
    
    Signed-off-by: Sergey Popovich <popovich_sergei@mail.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 156439bd5ca8f99ad08e12723a5f687719815b33
Author: Florian Westphal <fw@strlen.de>
Date:   Mon May 5 00:03:34 2014 +0200

    net: ipv6: send pkttoobig immediately if orig frag size > mtu
    
    [ Upstream commit 418a31561d594a2b636c1e2fa94ecd9e1245abb1 ]
    
    If conntrack defragments incoming ipv6 frags it stores largest original
    frag size in ip6cb and sets ->local_df.
    
    We must thus first test the largest original frag size vs. mtu, and not
    vice versa.
    
    Without this patch PKTTOOBIG is still generated in ip6_fragment() later
    in the stack, but
    
    1) IPSTATS_MIB_INTOOBIGERRORS won't increment
    2) packet did (needlessly) traverse netfilter postrouting hook.
    
    Fixes: fe6cc55f3a9 ("net: ip, ipv6: handle gso skbs in forwarding path")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b2b68efab92145a73420d86a2956fec786eda078
Author: Florian Westphal <fw@strlen.de>
Date:   Sun May 4 23:24:31 2014 +0200

    net: ipv4: ip_forward: fix inverted local_df test
    
    [ Upstream commit ca6c5d4ad216d5942ae544bbf02503041bd802aa ]
    
    local_df means 'ignore DF bit if set', so if its set we're
    allowed to perform ip fragmentation.
    
    This wasn't noticed earlier because the output path also drops such skbs
    (and emits needed icmp error) and because netfilter ip defrag did not
    set local_df until couple of days ago.
    
    Only difference is that DF-packets-larger-than MTU now discarded
    earlier (f.e. we avoid pointless netfilter postrouting trip).
    
    While at it, drop the repeated test ip_exceeds_mtu, checking it once
    is enough...
    
    Fixes: fe6cc55f3a9 ("net: ip, ipv6: handle gso skbs in forwarding path")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 90ca7e93604cfb1f11c2ebf8faf476b3b0ea2e1f
Author: Ying Cai <ycai@google.com>
Date:   Sun May 4 15:20:04 2014 -0700

    ip_tunnel: Set network header properly for IP_ECN_decapsulate()
    
    [ Upstream commit e96f2e7c430014eff52c93cabef1ad4f42ed0db1 ]
    
    In ip_tunnel_rcv(), set skb->network_header to inner IP header
    before IP_ECN_decapsulate().
    
    Without the fix, IP_ECN_decapsulate() takes outer IP header as
    inner IP header, possibly causing error messages or packet drops.
    
    Note that this skb_reset_network_header() call was in this spot when
    the original feature for checking consistency of ECN bits through
    tunnels was added in eccc1bb8d4b4 ("tunnel: drop packet if ECN present
    with not-ECT"). It was only removed from this spot in 3d7b46cd20e3
    ("ip_tunnel: push generic protocol handling to ip_tunnel module.").
    
    Fixes: 3d7b46cd20e3 ("ip_tunnel: push generic protocol handling to ip_tunnel module.")
    Reported-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Ying Cai <ycai@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 368986ee10b1739f9c2a400ac0fca0779c8fdc7e
Author: Andy King <acking@vmware.com>
Date:   Thu May 1 15:20:43 2014 -0700

    vsock: Make transport the proto owner
    
    [ Upstream commit 2c4a336e0a3e203fab6aa8d8f7bb70a0ad968a6b ]
    
    Right now the core vsock module is the owner of the proto family. This
    means there's nothing preventing the transport module from unloading if
    there are open sockets, which results in a panic. Fix that by allowing
    the transport to be the owner, which will refcount it properly.
    
    Includes version bump to 1.0.1.0-k
    
    Passes checkpatch this time, I swear...
    
    Acked-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Andy King <acking@vmware.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e78282a5759165273c4a704c842dc808e85b1780
Author: Liu Yu <allanyuliu@tencent.com>
Date:   Wed Apr 30 17:34:09 2014 +0800

    tcp_cubic: fix the range of delayed_ack
    
    [ Upstream commit 0cda345d1b2201dd15591b163e3c92bad5191745 ]
    
    commit b9f47a3aaeab (tcp_cubic: limit delayed_ack ratio to prevent
    divide error) try to prevent divide error, but there is still a little
    chance that delayed_ack can reach zero. In case the param cnt get
    negative value, then ratio+cnt would overflow and may happen to be zero.
    As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero.
    
    In some old kernels, such as 2.6.32, there is a bug that would
    pass negative param, which then ultimately leads to this divide error.
    
    commit 5b35e1e6e9c (tcp: fix tcp_trim_head() to adjust segment count
    with skb MSS) fixed the negative param issue. However,
    it's safe that we fix the range of delayed_ack as well,
    to make sure we do not hit a divide by zero.
    
    CC: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: Liu Yu <allanyuliu@tencent.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 04adf0fb0c5a2d52279ff6a2215dad9187bc9890
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Tue Apr 29 10:09:51 2014 -0400

    Revert "macvlan : fix checksums error when we are in bridge mode"
    
    [ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ]
    
    This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019.
    The commit above doesn't appear to be necessary any more as the
    checksums appear to be correctly computed/validated.
    
    Additionally the above commit breaks kvm configurations where
    one VM is using a device that support checksum offload (virtio) and
    the other VM does not.
    In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
    set.  The packets is forwarded to a macvtap that has offload features
    turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
    update the checksum and thus a bad checksum is passed up to
    the guest.
    
    CC: Daniel Lezcano <daniel.lezcano@free.fr>
    CC: Patrick McHardy <kaber@trash.net>
    CC: Andrian Nord <nightnord@gmail.com>
    CC: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Michael S. Tsirkin <mst@redhat.com>
    CC: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e8d41427c79ff1d922120faf7e4b46a060a3eed6
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Tue Apr 29 10:09:50 2014 -0400

    mactap: Fix checksum errors for non-gso packets in bridge mode
    
    [ Upstream commit cbdb04279ccaefcc702c8757757eea8ed76e50cf ]
    
    The following is a problematic configuration:
    
     VM1: virtio-net device connected to macvtap0@eth0
     VM2: e1000 device connect to macvtap1@eth0
    
    The problem is is that virtio-net supports checksum offloading
    and thus sends the packets to the host with CHECKSUM_PARTIAL set.
    On the other hand, e1000 does not support any acceleration.
    
    For small TCP packets (and this includes the 3-way handshake),
    e1000 ends up receiving packets that only have a partial checksum
    set.  This causes TCP to fail checksum validation and to drop
    packets.  As a result tcp connections can not be established.
    
    Commit 3e4f8b787370978733ca6cae452720a4f0c296b8
    	macvtap: Perform GSO on forwarding path.
    fixes this issue for large packets wthat will end up undergoing GSO.
    This commit adds a check for the non-GSO case and attempts to
    compute the checksum for partially checksummed packets in the
    non-GSO case.
    
    CC: Daniel Lezcano <daniel.lezcano@free.fr>
    CC: Patrick McHardy <kaber@trash.net>
    CC: Andrian Nord <nightnord@gmail.com>
    CC: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Michael S. Tsirkin <mst@redhat.com>
    CC: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 742bc1c6e156d8f55a23f39f7c6ddfd3ede7daa7
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Sat Apr 26 21:18:32 2014 +0200

    slip: fix spinlock variant
    
    [ Upstream commit ddcde142bed44490e338ed1124cb149976d355bb ]
    
    With commit cc9fa74e2a ("slip/slcan: added locking in wakeup function") a
    formerly missing locking was added to slip.c and slcan.c by Andre Naujoks.
    
    Alexander Stein contributed the fix 367525c8c2 ("can: slcan: Fix spinlock
    variant") as the kernel lock debugging advised to use spin_lock_bh() instead
    of just using spin_lock().
    
    This fix has to be applied to the same code section in slip.c for the same
    reason too.
    
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 692e923edc0bb0d58001c89d549df664ca909a2e
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:34 2014 +0200

    net: qmi_wwan: add a number of Dell devices
    
    [ Upstream commit 6f10c5d1b1aeddb63d33070abb8bc5a177beeb1f ]
    
    Dan writes:
    
    "The Dell drivers use the same configuration for PIDs:
    
    81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
    81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
    81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
    81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
    81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card
    
    These devices are all clearly Sierra devices, but are also definitely
    Gobi-based.  The A8 might be the MC7700/7710 and A9 is likely a MC7750.
    
    >From DellGobi5kSetup.exe from the Dell drivers:
    
    usbif0: serial/firmware loader?
    usbif2: nmea
    usbif3: modem/ppp
    usbif8: net/QMI"
    
    Reported-by: AceLan Kao <acelan.kao@canonical.com>
    Reported-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 66bafbb2c82db4202d790e08f12bb88587e71610
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:33 2014 +0200

    net: qmi_wwan: add a number of CMOTech devices
    
    [ Upstream commit 41be7d90993b1502d445bfc59e58348c258ce66a ]
    
    A number of older CMOTech modems are based on Qualcomm
    chips and exporting a QMI/wwan function.
    
    Reported-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ea942a5c1b5654a770b06dd557c8686ccd788028
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:32 2014 +0200

    net: qmi_wwan: add Alcatel L800MA
    
    [ Upstream commit 75573660c47a0db7cc931dcf154945610e02130a ]
    
    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/00/00 - serial AT+PPP
    2: ff/ff/ff - QMI/wwan
    3: 08/06/50 - storage
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 39e5bd5d344f8b937b5b88069ab23638de1f9b8e
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:31 2014 +0200

    net: qmi_wwan: add Olivetti Olicard 500
    
    [ Upstream commit efc0b25c3add97717ece57bf5319792ca98f348e ]
    
    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/ff/ff - serial AT+PPP
    2: 08/06/50 - storage
    3: ff/ff/ff - serial
    4: ff/ff/ff - QMI/wwan
    
    Reported-by: Julio Araujo <julio.araujo@wllctel.com.br>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f4d5e36953d02ba177007c61cd36a627f1a71295
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:30 2014 +0200

    net: qmi_wwan: add Sierra Wireless MC7305/MC7355
    
    [ Upstream commit 9214224e43e4264b02686ea8b455f310935607b5 ]
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d2945a5aa46663acbcbd7f027f778cdf3d33ef52
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:29 2014 +0200

    net: qmi_wwan: add Sierra Wireless MC73xx
    
    [ Upstream commit 1c138607a7be64074d7fba68d0d533ec38f9d17b ]
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 728d25ed51c708037ea64a07e056d079b719d2dc
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 19:00:28 2014 +0200

    net: qmi_wwan: add Sierra Wireless EM7355
    
    [ Upstream commit b85f5deaf052340021d025e120a9858f084a1d79 ]
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 90f00d5dfb56e03ffc41652ec75e76201bc3a3c7
Author: Xufeng Zhang <xufeng.zhang@windriver.com>
Date:   Fri Apr 25 16:55:41 2014 +0800

    sctp: reset flowi4_oif parameter on route lookup
    
    [ Upstream commit 85350871317a5adb35519d9dc6fc9e80809d42ad ]
    
    commit 813b3b5db83 (ipv4: Use caller's on-stack flowi as-is
    in output route lookups.) introduces another regression which
    is very similar to the problem of commit e6b45241c (ipv4: reset
    flowi parameters on route connect) wants to fix:
    Before we call ip_route_output_key() in sctp_v4_get_dst() to
    get a dst that matches a bind address as the source address,
    we have already called this function previously and the flowi
    parameters have been initialized including flowi4_oif, so when
    we call this function again, the process in __ip_route_output_key()
    will be different because of the setting of flowi4_oif, and we'll
    get a networking device which corresponds to the inputted flowi4_oif
    as the output device, this is wrong because we'll never hit this
    place if the previously returned source address of dst match one
    of the bound addresses.
    
    To reproduce this problem, a vlan setting is enough:
      # ifconfig eth0 up
      # route del default
      # vconfig add eth0 2
      # vconfig add eth0 3
      # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0
      # route add default gw 10.0.1.254 dev eth0.2
      # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0
      # ip rule add from 10.0.0.14 table 4
      # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3
      # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I
    You'll detect that all the flow are routed to eth0.2(10.0.1.254).
    
    Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c07ff54183d50d535ac2a9a10329a9fc38b5410a
Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date:   Fri Apr 25 17:01:18 2014 +0900

    bridge: Handle IFLA_ADDRESS correctly when creating bridge device
    
    [ Upstream commit 30313a3d5794472c3548d7288e306a5492030370 ]
    
    When bridge device is created with IFLA_ADDRESS, we are not calling
    br_stp_change_bridge_id(), which leads to incorrect local fdb
    management and bridge id calculation, and prevents us from receiving
    frames on the bridge device.
    
    Reported-by: Tom Gundersen <teg@jklm.no>
    Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f0b511cae2f0545e88ecd5cc7fcd0f9d7dac96c6
Author: Kumar Sundararajan <kumar@fb.com>
Date:   Thu Apr 24 09:48:53 2014 -0400

    ipv6: fib: fix fib dump restart
    
    [ Upstream commit 1c2658545816088477e91860c3a645053719cb54 ]
    
    When the ipv6 fib changes during a table dump, the walk is
    restarted and the number of nodes dumped are skipped. But the existing
    code doesn't advance to the next node after a node is skipped. This can
    cause the dump to loop or produce lots of duplicates when the fib
    is modified during the dump.
    
    This change advances the walk to the next node if the current node is
    skipped after a restart.
    
    Signed-off-by: Kumar Sundararajan <kumar@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e63f88ce95807539e4babe3c6fafe26529f1845c
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Thu Apr 24 10:22:36 2014 +1000

    rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set
    
    [ Upstream commit c53864fd60227de025cb79e05493b13f69843971 ]
    
    Since 115c9b81928360d769a76c632bae62d15206a94a (rtnetlink: Fix problem with
    buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST
    attribute if they were solicited by a GETLINK message containing an
    IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag.
    
    That was done because some user programs broke when they received more data
    than expected - because IFLA_VFINFO_LIST contains information for each VF
    it can become large if there are many VFs.
    
    However, the IFLA_VF_PORTS attribute, supplied for devices which implement
    ndo_get_vf_port (currently the 'enic' driver only), has the same problem.
    It supplies per-VF information and can therefore become large, but it is
    not currently conditional on the IFLA_EXT_MASK value.
    
    Worse, it interacts badly with the existing EXT_MASK handling.  When
    IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at
    NLMSG_GOODSIZE.  If the information for IFLA_VF_PORTS exceeds this, then
    rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet.
    netlink_dump() will misinterpret this as having finished the listing and
    omit data for this interface and all subsequent ones.  That can cause
    getifaddrs(3) to enter an infinite loop.
    
    This patch addresses the problem by only supplying IFLA_VF_PORTS when
    IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5a6aea7c0eaa0a2a851f80aa646ebb65d76c51fe
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Thu Apr 24 10:22:35 2014 +1000

    rtnetlink: Warn when interface's information won't fit in our packet
    
    [ Upstream commit 973462bbde79bb827824c73b59027a0aed5c9ca6 ]
    
    Without IFLA_EXT_MASK specified, the information reported for a single
    interface in response to RTM_GETLINK is expected to fit within a netlink
    packet of NLMSG_GOODSIZE.
    
    If it doesn't, however, things will go badly wrong,  When listing all
    interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first
    message in a packet as the end of the listing and omit information for
    that interface and all subsequent ones.  This can cause getifaddrs(3) to
    enter an infinite loop.
    
    This patch won't fix the problem, but it will WARN_ON() making it easier to
    track down what's going wrong.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6bebcc8d95669e32c9ac6e836e985ae50392ae23
Author: Andrew Lutomirski <luto@amacapital.net>
Date:   Wed Apr 16 21:41:34 2014 -0700

    net: Fix ns_capable check in sock_diag_put_filterinfo
    
    [ Upstream commit 78541c1dc60b65ecfce5a6a096fc260219d6784e ]
    
    The caller needs capabilities on the namespace being queried, not on
    their own namespace.  This is a security bug, although it likely has
    only a minor impact.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 88830f227a1f96e44d82ddfcb0cc81d517ec6dd8
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Thu Apr 17 17:26:50 2014 +0200

    net: sctp: cache auth_enable per endpoint
    
    [ Upstream commit b14878ccb7fac0242db82720b784ab62c467c0dc ]
    
    Currently, it is possible to create an SCTP socket, then switch
    auth_enable via sysctl setting to 1 and crash the system on connect:
    
    Oops[#1]:
    CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.1-mipsgit-20140415 #1
    task: ffffffff8056ce80 ti: ffffffff8055c000 task.ti: ffffffff8055c000
    [...]
    Call Trace:
    [<ffffffff8043c4e8>] sctp_auth_asoc_set_default_hmac+0x68/0x80
    [<ffffffff8042b300>] sctp_process_init+0x5e0/0x8a4
    [<ffffffff8042188c>] sctp_sf_do_5_1B_init+0x234/0x34c
    [<ffffffff804228c8>] sctp_do_sm+0xb4/0x1e8
    [<ffffffff80425a08>] sctp_endpoint_bh_rcv+0x1c4/0x214
    [<ffffffff8043af68>] sctp_rcv+0x588/0x630
    [<ffffffff8043e8e8>] sctp6_rcv+0x10/0x24
    [<ffffffff803acb50>] ip6_input+0x2c0/0x440
    [<ffffffff8030fc00>] __netif_receive_skb_core+0x4a8/0x564
    [<ffffffff80310650>] process_backlog+0xb4/0x18c
    [<ffffffff80313cbc>] net_rx_action+0x12c/0x210
    [<ffffffff80034254>] __do_softirq+0x17c/0x2ac
    [<ffffffff800345e0>] irq_exit+0x54/0xb0
    [<ffffffff800075a4>] ret_from_irq+0x0/0x4
    [<ffffffff800090ec>] rm7k_wait_irqoff+0x24/0x48
    [<ffffffff8005e388>] cpu_startup_entry+0xc0/0x148
    [<ffffffff805a88b0>] start_kernel+0x37c/0x398
    Code: dd0900b8  000330f8  0126302d <dcc60000> 50c0fff1  0047182a  a48306a0
    03e00008  00000000
    ---[ end trace b530b0551467f2fd ]---
    Kernel panic - not syncing: Fatal exception in interrupt
    
    What happens while auth_enable=0 in that case is, that
    ep->auth_hmacs is initialized to NULL in sctp_auth_init_hmacs()
    when endpoint is being created.
    
    After that point, if an admin switches over to auth_enable=1,
    the machine can crash due to NULL pointer dereference during
    reception of an INIT chunk. When we enter sctp_process_init()
    via sctp_sf_do_5_1B_init() in order to respond to an INIT chunk,
    the INIT verification succeeds and while we walk and process
    all INIT params via sctp_process_param() we find that
    net->sctp.auth_enable is set, therefore do not fall through,
    but invoke sctp_auth_asoc_set_default_hmac() instead, and thus,
    dereference what we have set to NULL during endpoint
    initialization phase.
    
    The fix is to make auth_enable immutable by caching its value
    during endpoint initialization, so that its original value is
    being carried along until destruction. The bug seems to originate
    from the very first days.
    
    Fix in joint work with Daniel Borkmann.
    
    Reported-by: Joshua Kinard <kumba@gentoo.org>
    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Tested-by: Joshua Kinard <kumba@gentoo.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6341e247c4ef83688fbdb8b30a3ddfe1e4e40703
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Apr 17 14:51:08 2014 +0200

    tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled
    
    The patch fixes a problem with dropped jumbo frames after usage of
    'ethtool -G ... rx'.
    
    Scenario:
    1. ip link set eth0 up
    2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo
    3. ip link set mtu 9000 dev eth0
    
    The ethtool command set rx_jumbo_pending to zero so any received jumbo
    packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N'
    to workaround the issue.
    The patch changes the logic so rx_jumbo_pending value is changed only if
    jumbo frames are enabled (MTU > 1500).
    
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 059590c8e26afc293aa92d64964038ed35abca3e
Author: dingtianhong <dingtianhong@huawei.com>
Date:   Thu Apr 17 18:40:36 2014 +0800

    vlan: Fix lockdep warning when vlan dev handle notification
    
    [ Upstream commit dc8eaaa006350d24030502a4521542e74b5cb39f ]
    
    When I open the LOCKDEP config and run these steps:
    
    modprobe 8021q
    vconfig add eth2 20
    vconfig add eth2.20 30
    ifconfig eth2 xx.xx.xx.xx
    
    then the Call Trace happened:
    
    [32524.386288] =============================================
    [32524.386293] [ INFO: possible recursive locking detected ]
    [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G           O
    [32524.386302] ---------------------------------------------
    [32524.386306] ifconfig/3103 is trying to acquire lock:
    [32524.386310]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
    [32524.386326]
    [32524.386326] but task is already holding lock:
    [32524.386330]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
    [32524.386341]
    [32524.386341] other info that might help us debug this:
    [32524.386345]  Possible unsafe locking scenario:
    [32524.386345]
    [32524.386350]        CPU0
    [32524.386352]        ----
    [32524.386354]   lock(&vlan_netdev_addr_lock_key/1);
    [32524.386359]   lock(&vlan_netdev_addr_lock_key/1);
    [32524.386364]
    [32524.386364]  *** DEADLOCK ***
    [32524.386364]
    [32524.386368]  May be due to missing lock nesting notation
    [32524.386368]
    [32524.386373] 2 locks held by ifconfig/3103:
    [32524.386376]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81431d42>] rtnl_lock+0x12/0x20
    [32524.386387]  #1:  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
    [32524.386398]
    [32524.386398] stack backtrace:
    [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G           O 3.14.0-rc2-0.7-default+ #35
    [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [32524.386414]  ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
    [32524.386421]  ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
    [32524.386428]  000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
    [32524.386435] Call Trace:
    [32524.386441]  [<ffffffff814f68a2>] dump_stack+0x6a/0x78
    [32524.386448]  [<ffffffff810a35fb>] __lock_acquire+0x7ab/0x1940
    [32524.386454]  [<ffffffff810a323a>] ? __lock_acquire+0x3ea/0x1940
    [32524.386459]  [<ffffffff810a4874>] lock_acquire+0xe4/0x110
    [32524.386464]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
    [32524.386471]  [<ffffffff814fc07a>] _raw_spin_lock_nested+0x2a/0x40
    [32524.386476]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
    [32524.386481]  [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
    [32524.386489]  [<ffffffffa0500cab>] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
    [32524.386495]  [<ffffffff8141addf>] __dev_set_rx_mode+0x5f/0xb0
    [32524.386500]  [<ffffffff8141af8b>] dev_set_rx_mode+0x2b/0x40
    [32524.386506]  [<ffffffff8141b3cf>] __dev_open+0xef/0x150
    [32524.386511]  [<ffffffff8141b177>] __dev_change_flags+0xa7/0x190
    [32524.386516]  [<ffffffff8141b292>] dev_change_flags+0x32/0x80
    [32524.386524]  [<ffffffff8149ca56>] devinet_ioctl+0x7d6/0x830
    [32524.386532]  [<ffffffff81437b0b>] ? dev_ioctl+0x34b/0x660
    [32524.386540]  [<ffffffff814a05b0>] inet_ioctl+0x80/0xa0
    [32524.386550]  [<ffffffff8140199d>] sock_do_ioctl+0x2d/0x60
    [32524.386558]  [<ffffffff81401a52>] sock_ioctl+0x82/0x2a0
    [32524.386568]  [<ffffffff811a7123>] do_vfs_ioctl+0x93/0x590
    [32524.386578]  [<ffffffff811b2705>] ? rcu_read_lock_held+0x45/0x50
    [32524.386586]  [<ffffffff811b39e5>] ? __fget_light+0x105/0x110
    [32524.386594]  [<ffffffff811a76b1>] SyS_ioctl+0x91/0xb0
    [32524.386604]  [<ffffffff815057e2>] system_call_fastpath+0x16/0x1b
    
    ========================================================================
    
    The reason is that all of the addr_lock_key for vlan dev have the same class,
    so if we change the status for vlan dev, the vlan dev and its real dev will
    hold the same class of addr_lock_key together, so the warning happened.
    
    we should distinguish the lock depth for vlan dev and its real dev.
    
    v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
    	could support to add 8 vlan id on a same vlan dev, I think it is enough for current
    	scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
    	and the vlan dev would not meet the same class key with its real dev.
    
    	The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
    	dev could get a suitable class key.
    
    v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
    	and its real dev, but it make no sense, because the difference for subclass in the
    	lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
    	to distinguish the different depth for every vlan dev, the same depth of the vlan dev
    	could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
    	I think it is enough here, the lockdep should never exceed that value.
    
    v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
    	we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
    	and use the depth as the subclass for addr_lock_key.
    
    Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3565e1853b7ac1104a1eb56360c3bf1d4419660b
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Mon Apr 14 17:11:38 2014 +0200

    ip6_gre: don't allow to remove the fb_tunnel_dev
    
    [ Upstream commit 54d63f787b652755e66eb4dd8892ee6d3f5197fc ]
    
    It's possible to remove the FB tunnel with the command 'ip link del ip6gre0' but
    this is unsafe, the module always supposes that this device exists. For example,
    ip6gre_tunnel_lookup() may use it unconditionally.
    
    Let's add a rtnl handler for dellink, which will never remove the FB tunnel (we
    let ip6gre_destroy_tunnels() do the job).
    
    Introduced by commit c12b395a4664 ("gre: Support GRE over IPv6").
    
    CC: Dmitry Kozlov <xeb@mail.ru>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dd6e370c0083e0382782893708b5241490ea6832
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 13 18:23:33 2014 +0200

    filter: prevent nla extensions to peek beyond the end of the message
    
    [ Upstream commit 05ab8f2647e4221cbdb3856dd7d32bd5407316b3 ]
    
    The BPF_S_ANC_NLATTR and BPF_S_ANC_NLATTR_NEST extensions fail to check
    for a minimal message length before testing the supplied offset to be
    within the bounds of the message. This allows the subtraction of the nla
    header to underflow and therefore -- as the data type is unsigned --
    allowing far to big offset and length values for the search of the
    netlink attribute.
    
    The remainder calculation for the BPF_S_ANC_NLATTR_NEST extension is
    also wrong. It has the minuend and subtrahend mixed up, therefore
    calculates a huge length value, allowing to overrun the end of the
    message while looking for the netlink attribute.
    
    The following three BPF snippets will trigger the bugs when attached to
    a UNIX datagram socket and parsing a message with length 1, 2 or 3.
    
     ,-[ PoC for missing size check in BPF_S_ANC_NLATTR ]--
     | ld	#0x87654321
     | ldx	#42
     | ld	#nla
     | ret	a
     `---
    
     ,-[ PoC for the same bug in BPF_S_ANC_NLATTR_NEST ]--
     | ld	#0x87654321
     | ldx	#42
     | ld	#nlan
     | ret	a
     `---
    
     ,-[ PoC for wrong remainder calculation in BPF_S_ANC_NLATTR_NEST ]--
     | ; (needs a fake netlink header at offset 0)
     | ld	#0
     | ldx	#42
     | ld	#nlan
     | ret	a
     `---
    
    Fix the first issue by ensuring the message length fulfills the minimal
    size constrains of a nla header. Fix the second bug by getting the math
    for the remainder calculation right.
    
    Fixes: 4738c1db15 ("[SKFILTER]: Add SKF_ADF_NLATTR instruction")
    Fixes: d214c7537b ("filter: add SKF_AD_NLATTR_NEST to look for nested..")
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Acked-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d3fe9147a60663d3329e557df9edbfdb2fdedde3
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sun Apr 13 18:08:02 2014 +0300

    ipv4: return valid RTA_IIF on ip route get
    
    [ Upstream commit 91146153da2feab18efab2e13b0945b6bb704ded ]
    
    Extend commit 13378cad02afc2adc6c0e07fca03903c7ada0b37
    ("ipv4: Change rt->rt_iif encoding.") from 3.6 to return valid
    RTA_IIF on 'ip route get ... iif DEVICE' instead of rt_iif 0
    which is displayed as 'iif *'.
    
    inet_iif is not appropriate to use because skb_iif is not set.
    Use the skb->dev->ifindex instead.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8e41d3a008374022b116ed4434dec644fef3e676
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Fri Apr 11 15:51:19 2014 +0200

    vti: don't allow to add the same tunnel twice
    
    [ Upstream commit 8d89dcdf80d88007647945a753821a06eb6cc5a5 ]
    
    Before the patch, it was possible to add two times the same tunnel:
    ip l a vti1 type vti remote 10.16.0.121 local 10.16.0.249 key 41
    ip l a vti2 type vti remote 10.16.0.121 local 10.16.0.249 key 41
    
    It was possible, because ip_tunnel_newlink() calls ip_tunnel_find() with the
    argument dev->type, which was set only later (when calling ndo_init handler
    in register_netdevice()). Let's set this type in the setup handler, which is
    called before newlink handler.
    
    Introduced by commit b9959fd3b0fa ("vti: switch to new ip tunnel code").
    
    CC: Cong Wang <amwang@redhat.com>
    CC: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d6f8502e676b405e195eee423ae5d70096b1c282
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Fri Apr 11 15:51:18 2014 +0200

    gre: don't allow to add the same tunnel twice
    
    [ Upstream commit 5a4552752d8f7f4cef1d98775ece7adb7616fde2 ]
    
    Before the patch, it was possible to add two times the same tunnel:
    ip l a gre1 type gre remote 10.16.0.121 local 10.16.0.249
    ip l a gre2 type gre remote 10.16.0.121 local 10.16.0.249
    
    It was possible, because ip_tunnel_newlink() calls ip_tunnel_find() with the
    argument dev->type, which was set only later (when calling ndo_init handler
    in register_netdevice()). Let's set this type in the setup handler, which is
    called before newlink handler.
    
    Introduced by commit c54419321455 ("GRE: Refactor GRE tunneling code.").
    
    CC: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0e6961b3b263e8d4278607f00889575f1eb75bf3
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Apr 10 21:23:36 2014 -0700

    ipv6: Limit mtu to 65575 bytes
    
    [ Upstream commit 30f78d8ebf7f514801e71b88a10c948275168518 ]
    
    Francois reported that setting big mtu on loopback device could prevent
    tcp sessions making progress.
    
    We do not support (yet ?) IPv6 Jumbograms and cook corrupted packets.
    
    We must limit the IPv6 MTU to (65535 + 40) bytes in theory.
    
    Tested:
    
    ifconfig lo mtu 70000
    netperf -H ::1
    
    Before patch : Throughput :   0.05 Mbits
    
    After patch : Throughput : 35484 Mbits
    
    Reported-by: Francois WELLENREITER <f.wellenreiter@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 262cacfba2c885aa7b45433e824eb67636323c65
Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date:   Wed Apr 9 17:00:30 2014 +0900

    bridge: Fix double free and memory leak around br_allowed_ingress
    
    [ Upstream commit eb7076182d1ae4bc4641534134ed707100d76acc ]
    
    br_allowed_ingress() has two problems.
    
    1. If br_allowed_ingress() is called by br_handle_frame_finish() and
    vlan_untag() in br_allowed_ingress() fails, skb will be freed by both
    vlan_untag() and br_handle_frame_finish().
    
    2. If br_allowed_ingress() is called by br_dev_xmit() and
    br_allowed_ingress() fails, the skb will not be freed.
    
    Fix these two problems by freeing the skb in br_allowed_ingress()
    if it fails.
    
    Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2a0fe092c7eb575a56956ce9dc55a02fe69c3a31
Author: Thomas Richter <tmricht@linux.vnet.ibm.com>
Date:   Wed Apr 9 12:52:59 2014 +0200

    bonding: Remove debug_fs files when module init fails
    
    [ Upstream commit db29868653394937037d71dc3545768302dda643 ]
    
    Remove the bonding debug_fs entries when the
    module initialization fails. The debug_fs
    entries should be removed together with all other
    already allocated resources.
    
    Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Signed-off-by: Jay Vosburgh <j.vosburgh@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6a80e19b4cc257a0291920157a6c1749e138e268
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Apr 9 10:28:50 2014 +0200

    net: core: don't account for udp header size when computing seglen
    
    [ Upstream commit 6d39d589bb76ee8a1c6cde6822006ae0053decff ]
    
    In case of tcp, gso_size contains the tcpmss.
    
    For UFO (udp fragmentation offloading) skbs, gso_size is the fragment
    payload size, i.e. we must not account for udp header size.
    
    Otherwise, when using virtio drivers, a to-be-forwarded UFO GSO packet
    will be needlessly fragmented in the forward path, because we think its
    individual segments are too large for the outgoing link.
    
    Fixes: fe6cc55f3a9a053 ("net: ip, ipv6: handle gso skbs in forwarding path")
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Reported-by: Tobias Brunner <tobias@strongswan.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 528738eb2da4924b5f8d74e99945bca1f9ca7bbd
Author: Dmitry Petukhov <dmgenp@gmail.com>
Date:   Wed Apr 9 02:23:20 2014 +0600

    l2tp: take PMTU from tunnel UDP socket
    
    [ Upstream commit f34c4a35d87949fbb0e0f31eba3c054e9f8199ba ]
    
    When l2tp driver tries to get PMTU for the tunnel destination, it uses
    the pointer to struct sock that represents PPPoX socket, while it
    should use the pointer that represents UDP socket of the tunnel.
    
    Signed-off-by: Dmitry Petukhov <dmgenp@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 568491238ce069e51b20768f66c1449d4fb43807
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Apr 9 16:10:20 2014 +0200

    net: sctp: test if association is dead in sctp_wake_up_waiters
    
    [ Upstream commit 1e1cdf8ac78793e0875465e98a648df64694a8d0 ]
    
    In function sctp_wake_up_waiters(), we need to involve a test
    if the association is declared dead. If so, we don't have any
    reference to a possible sibling association anymore and need
    to invoke sctp_write_space() instead, and normally walk the
    socket's associations and notify them of new wmem space. The
    reason for special casing is that otherwise, we could run
    into the following issue when a sctp_primitive_SEND() call
    from sctp_sendmsg() fails, and tries to flush an association's
    outq, i.e. in the following way:
    
    sctp_association_free()
    `-> list_del(&asoc->asocs)         <-- poisons list pointer
        asoc->base.dead = true
        sctp_outq_free(&asoc->outqueue)
        `-> __sctp_outq_teardown()
         `-> sctp_chunk_free()
          `-> consume_skb()
           `-> sctp_wfree()
            `-> sctp_wake_up_waiters() <-- dereferences poisoned pointers
                                           if asoc->ep->sndbuf_policy=0
    
    Therefore, only walk the list in an 'optimized' way if we find
    that the current association is still active. We could also use
    list_del_init() in addition when we call sctp_association_free(),
    but as Vlad suggests, we want to trap such bugs and thus leave
    it poisoned as is.
    
    Why is it safe to resolve the issue by testing for asoc->base.dead?
    Parallel calls to sctp_sendmsg() are protected under socket lock,
    that is lock_sock()/release_sock(). Only within that path under
    lock held, we're setting skb/chunk owner via sctp_set_owner_w().
    Eventually, chunks are freed directly by an association still
    under that lock. So when traversing association list on destruction
    time from sctp_wake_up_waiters() via sctp_wfree(), a different
    CPU can't be running sctp_wfree() while another one calls
    sctp_association_free() as both happens under the same lock.
    Therefore, this can also not race with setting/testing against
    asoc->base.dead as we are guaranteed for this to happen in order,
    under lock. Further, Vlad says: the times we check asoc->base.dead
    is when we've cached an association pointer for later processing.
    In between cache and processing, the association may have been
    freed and is simply still around due to reference counts. We check
    asoc->base.dead under a lock, so it should always be safe to check
    and not race against sctp_association_free(). Stress-testing seems
    fine now, too.
    
    Fixes: cd253f9f357d ("net: sctp: wake up all assocs if sndbuf policy is per socket")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 13d6a70cadb22ae71f62ad56752451fa848fc346
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Tue Apr 8 17:26:13 2014 +0200

    net: sctp: wake up all assocs if sndbuf policy is per socket
    
    [ Upstream commit 52c35befb69b005c3fc5afdaae3a5717ad013411 ]
    
    SCTP charges chunks for wmem accounting via skb->truesize in
    sctp_set_owner_w(), and sctp_wfree() respectively as the
    reverse operation. If a sender runs out of wmem, it needs to
    wait via sctp_wait_for_sndbuf(), and gets woken up by a call
    to __sctp_write_space() mostly via sctp_wfree().
    
    __sctp_write_space() is being called per association. Although
    we assign sk->sk_write_space() to sctp_write_space(), which
    is then being done per socket, it is only used if send space
    is increased per socket option (SO_SNDBUF), as SOCK_USE_WRITE_QUEUE
    is set and therefore not invoked in sock_wfree().
    
    Commit 4c3a5bdae293 ("sctp: Don't charge for data in sndbuf
    again when transmitting packet") fixed an issue where in case
    sctp_packet_transmit() manages to queue up more than sndbuf
    bytes, sctp_wait_for_sndbuf() will never be woken up again
    unless it is interrupted by a signal. However, a still
    remaining issue is that if net.sctp.sndbuf_policy=0, that is
    accounting per socket, and one-to-many sockets are in use,
    the reclaimed write space from sctp_wfree() is 'unfairly'
    handed back on the server to the association that is the lucky
    one to be woken up again via __sctp_write_space(), while
    the remaining associations are never be woken up again
    (unless by a signal).
    
    The effect disappears with net.sctp.sndbuf_policy=1, that
    is wmem accounting per association, as it guarantees a fair
    share of wmem among associations.
    
    Therefore, if we have reclaimed memory in case of per socket
    accounting, wake all related associations to a socket in a
    fair manner, that is, traverse the socket association list
    starting from the current neighbour of the association and
    issue a __sctp_write_space() to everyone until we end up
    waking ourselves. This guarantees that no association is
    preferred over another and even if more associations are
    taken into the one-to-many session, all receivers will get
    messages from the server and are not stalled forever on
    high load. This setting still leaves the advantage of per
    socket accounting in touch as an association can still use
    up global limits if unused by others.
    
    Fixes: 4eb701dfc618 ("[SCTP] Fix SCTP sendbuffer accouting.")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Thomas Graf <tgraf@suug.ch>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 007f639ee9166b2ecd7357dd7773e1d855e74c2e
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Mar 28 08:54:04 2014 +0200

    drm/i915/tv: fix gen4 composite s-video tv-out
    
    commit e1f23f3dd817f53f622e486913ac662add46eeed upstream.
    
    This is *not* bisected, but the likely regression is
    
    commit c35614380d5c956bfda20eab2755b2f5a7d6f1e7
    Author: Zhao Yakui <yakui.zhao@intel.com>
    Date:   Tue Nov 24 09:48:48 2009 +0800
    
        drm/i915: Don't set up the TV port if it isn't in the BIOS table.
    
    The commit does not check for all TV device types that might be present
    in the VBT, disabling TV out for the missing ones. Add composite
    S-video.
    
    Reported-and-tested-by: Matthew Khouzam <matthew.khouzam@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73362
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 946a34f2de502fd9b29871f41903c2197fc81733
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Wed Apr 2 08:42:49 2014 -0400

    drm/radeon: fix typo in spectre_golden_registers
    
    commit f1553174a207f68a4ec19d436003097e0a4dc405 upstream.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 65ee719ca5d1f9ebc85736f1ef866e8c0bc84a73
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Mon Mar 31 11:19:46 2014 -0400

    drm/radeon: call drm_edid_to_eld when we update the edid
    
    commit 16086279353cbfecbb3ead474072dced17b97ddc upstream.
    
    This needs to be done to update some of the fields in
    the connector structure used by the audio code.
    
    Noticed by several users on irc.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 657ac32e6a1cf38f6f2380cb075ab6fd56498c0f
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date:   Tue Apr 1 15:15:47 2014 +0200

    drm/qxl: unset a pointer in sync_obj_unref
    
    commit 41ccec352f3c823931a7d9d2a9c7880c14d7415a upstream.
    
    This fixes a BUG_ON(bo->sync_obj != NULL); in ttm_bo_release_list.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e826b6c6640660db799f6c8344f40447e76036e8
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Apr 15 18:25:48 2014 +0200

    drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
    
    commit cbd75e97a525e3819c02dc18bc2d67aa544c9e45 upstream.
    
    We already check that the buffer object we're accessing is registered with
    the file. Now also make sure that we can't DMA across buffer object boundaries.
    
    v2: Code commenting update.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e30112b512c46e5fbf87b444aadab5154bc8cceb
Author: Christopher Friedt <chrisfriedt@gmail.com>
Date:   Sat Feb 1 10:01:15 2014 -0500

    drm/vmwgfx: correct fb_fix_screeninfo.line_length
    
    commit aa6de142c901cd2d90ef08db30ae87da214bedcc upstream.
    
    Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust
    the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour.
    
    See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.
    
    Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c36604fe10ee69babe452bf5f888185ef163cd39
Author: Thomas Bächler <thomas@archlinux.org>
Date:   Thu Apr 3 21:55:37 2014 +0200

    fs: Don't return 0 from get_anon_bdev
    
    commit a2a4dc494a7b7135f460e38e788c4a58f65e4ac3 upstream.
    
    Commit 9e30cc9595303b27b48 removed an internal mount. This
    has the side-effect that rootfs now has FSID 0. Many
    userspace utilities assume that st_dev in struct stat
    is never 0, so this change breaks a number of tools in
    early userspace.
    
    Since we don't know how many userspace programs are affected,
    make sure that FSID is at least 1.
    
    References: http://article.gmane.org/gmane.linux.kernel/1666905
    References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557
    Signed-off-by: Thomas Bächler <thomas@archlinux.org>
    Acked-by: Tejun Heo <tj@kernel.org>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0610ae43cefde18c9270e7c791faa629382200f1
Author: Chris Mason <clm@fb.com>
Date:   Tue Apr 15 18:09:24 2014 -0400

    mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll
    
    commit c98235cb8584a72e95786e17d695a8e5fafcd766 upstream.
    
    The mlx4 driver is triggering schedules while atomic inside
    mlx4_en_netpoll:
    
    	spin_lock_irqsave(&cq->lock, flags);
    	napi_synchronize(&cq->napi);
    		^^^^^ msleep here
    	mlx4_en_process_rx_cq(dev, cq, 0);
    	spin_unlock_irqrestore(&cq->lock, flags);
    
    This was part of a patch by Alexander Guller from Mellanox in 2011,
    but it still isn't upstream.
    
    Signed-off-by: Chris Mason <clm@fb.com>
    Acked-By: Amir Vadai <amirv@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5ba3b1ee9254602486b6a62780d775461a490d4d
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:20 2014 +0200

    usb: option: add and update a number of CMOTech devices
    
    commit 34f972d6156fe9eea2ab7bb418c71f9d1d5c8e7b upstream.
    
    A number of older CMOTech modems are based on Qualcomm
    chips.  The blacklisted interfaces are QMI/wwan.
    
    Reported-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 42f2c7fb3ea7029dcde2387418b33538440c2a88
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:19 2014 +0200

    usb: option: add Alcatel L800MA
    
    commit dd6b48ecec2ea7d15f28d5e5474388681899a5e1 upstream.
    
    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/00/00 - serial AT+PPP
    2: ff/ff/ff - QMI/wwan
    3: 08/06/50 - storage
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 225f31b02e53e533a21922f207ea92f0c1c14a26
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:18 2014 +0200

    usb: option: add Olivetti Olicard 500
    
    commit 533b3994610f316e5cd61b56d0c4daa15c830f89 upstream.
    
    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/ff/ff - serial AT+PPP
    2: 08/06/50 - storage
    3: ff/ff/ff - serial
    4: ff/ff/ff - QMI/wwan
    
    Reported-by: Julio Araujo <julio.araujo@wllctel.com.br>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit aa707d08b60e0c7f4261b886949a3403e7ae0b64
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:17 2014 +0200

    usb: qcserial: add Sierra Wireless MC7305/MC7355
    
    commit bce4f588f19d59fc07fadfeb0b2a3a06c942827a upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 47c41d33c7398409dbd677c353eff6bcf87da2f4
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:16 2014 +0200

    usb: qcserial: add Sierra Wireless MC73xx
    
    commit 70a3615fc07c2330ed7c1e922f3c44f4a67c0762 upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6da60ef3c3f1101992510501b1f387c69673a610
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Apr 25 18:49:15 2014 +0200

    usb: qcserial: add Sierra Wireless EM7355
    
    commit a00986f81182a69dee4d2c48e8c19805bdf0f790 upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cc5aeeb5c66a30b9be357ccec62f51b29b136606
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Apr 25 15:23:03 2014 +0200

    USB: io_ti: fix firmware download on big-endian machines
    
    commit 5509076d1b4485ce9fb07705fcbcd2695907ab5b upstream.
    
    During firmware download the device expects memory addresses in
    big-endian byte order. As the wIndex parameter which hold the address is
    sent in little-endian byte order regardless of host byte order, we need
    to use swab16 rather than cpu_to_be16.
    
    Also make sure to handle the struct ti_i2c_desc size parameter which is
    returned in little-endian byte order.
    
    Reported-by: Ludovic Drolez <ldrolez@debian.org>
    Tested-by: Ludovic Drolez <ldrolez@debian.org>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e53acf9754734aa0d58686494f640c00445316c3
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Apr 23 11:32:19 2014 +0200

    USB: serial: fix sysfs-attribute removal deadlock
    
    commit 10164c2ad6d2c16809f6c09e278f946e47801b3a upstream.
    
    Fix driver new_id sysfs-attribute removal deadlock by making sure to
    not hold any locks that the attribute operations grab when removing the
    attribute.
    
    Specifically, usb_serial_deregister holds the table mutex when
    deregistering the driver, which includes removing the new_id attribute.
    This can lead to a deadlock as writing to new_id increments the
    attribute's active count before trying to grab the same mutex in
    usb_serial_probe.
    
    The deadlock can easily be triggered by inserting a sleep in
    usb_serial_deregister and writing the id of an unbound device to new_id
    during module unload.
    
    As the table mutex (in this case) is used to prevent subdriver unload
    during probe, it should be sufficient to only hold the lock while
    manipulating the usb-serial driver list during deregister. A racing
    probe will then either fail to find a matching subdriver or fail to get
    the corresponding module reference.
    
    Since v3.15-rc1 this also triggers the following lockdep warning:
    
    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.15.0-rc2 #123 Tainted: G        W
    -------------------------------------------------------
    modprobe/190 is trying to acquire lock:
     (s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
    
    but task is already holding lock:
     (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (table_lock){+.+.+.}:
           [<c0075f84>] __lock_acquire+0x1694/0x1ce4
           [<c0076de8>] lock_acquire+0xb4/0x154
           [<c03af3cc>] _raw_spin_lock+0x4c/0x5c
           [<c02bbc24>] usb_store_new_id+0x14c/0x1ac
           [<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
           [<c025f568>] drv_attr_store+0x30/0x3c
           [<c01690e0>] sysfs_kf_write+0x5c/0x60
           [<c01682c0>] kernfs_fop_write+0xd4/0x194
           [<c010881c>] vfs_write+0xbc/0x198
           [<c0108e4c>] SyS_write+0x4c/0xa0
           [<c000f880>] ret_fast_syscall+0x0/0x48
    
    -> #0 (s_active#4){++++.+}:
           [<c03a7a28>] print_circular_bug+0x68/0x2f8
           [<c0076218>] __lock_acquire+0x1928/0x1ce4
           [<c0076de8>] lock_acquire+0xb4/0x154
           [<c0166b70>] __kernfs_remove+0x254/0x310
           [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
           [<c0169fb8>] remove_files.isra.1+0x48/0x84
           [<c016a2fc>] sysfs_remove_group+0x58/0xac
           [<c016a414>] sysfs_remove_groups+0x34/0x44
           [<c02623b8>] driver_remove_groups+0x1c/0x20
           [<c0260e9c>] bus_remove_driver+0x3c/0xe4
           [<c026235c>] driver_unregister+0x38/0x58
           [<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
           [<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
           [<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
           [<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
           [<c009d6cc>] SyS_delete_module+0x184/0x210
           [<c000f880>] ret_fast_syscall+0x0/0x48
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(table_lock);
                                   lock(s_active#4);
                                   lock(table_lock);
      lock(s_active#4);
    
     *** DEADLOCK ***
    
    1 lock held by modprobe/190:
     #0:  (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
    
    stack backtrace:
    CPU: 0 PID: 190 Comm: modprobe Tainted: G        W     3.15.0-rc2 #123
    [<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
    [<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
    [<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
    [<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
    [<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
    [<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
    [<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
    [<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
    [<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
    [<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
    [<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
    [<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
    [<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
    [<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
    [<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
    [<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
    [<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
    [<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
    [<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8e3e396462c30221a7ed37cdcf065ecf585c310d
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Mar 28 18:05:10 2014 +0100

    Revert "USB: serial: add usbid for dell wwan card to sierra.c"
    
    commit 2e01280d2801c72878cf3a7119eac30077b463d5 upstream.
    
    This reverts commit 1ebca9dad5abe8b2ed4dbd186cd657fb47c1f321.
    
    This device was erroneously added to the sierra driver even though it's
    not a Sierra device and was already handled by the option driver.
    
    Cc: Richard Farina <sidhayn@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8ee84f2cdd9ef7772e1638be5cb66716ff614179
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed Apr 2 11:19:48 2014 +0200

    usb: option driver, add support for Telit UE910v2
    
    commit d6de486bc22255779bd54b0fceb4c240962bf146 upstream.
    
    option driver, added VID/PID for Telit UE910v2 modem
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6258d2c043ca5db1f8a35893cac9f7c313a1cf34
Author: Michele Baldessari <michele@acksyn.org>
Date:   Mon Mar 31 10:51:00 2014 +0200

    USB: serial: ftdi_sio: add id for Brainboxes serial cards
    
    commit efe26e16b1d93ac0085e69178cc18811629e8fc5 upstream.
    
    Custom VID/PIDs for Brainboxes cards as reported in
    https://bugzilla.redhat.com/show_bug.cgi?id=1071914
    
    Signed-off-by: Michele Baldessari <michele@acksyn.org>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f17c4324018727f3cfc767889cd496aac0e7c7e1
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Apr 3 13:06:46 2014 +0200

    USB: usb_wwan: fix handling of missing bulk endpoints
    
    commit bd73bd8831696f189a479a0712ae95208e513d7e upstream.
    
    Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
    bulk-urb allocation") by making sure to require both bulk-in and out
    endpoints during port probe.
    
    The original option driver (which usb_wwan is based on) was written
    under the assumption that either endpoint could be missing, but
    evidently this cannot have been tested properly. Specifically, it would
    handle opening a device without bulk-in (but would blow up during resume
    which was implemented later), but not a missing bulk-out in write()
    (although it is handled in some places such as write_room()).
    
    Fortunately (?), the driver also got the test for missing endpoints
    wrong so the urbs were in fact always allocated, although they would be
    initialised using the wrong endpoint address (0) and any submission of
    such an urb would fail.
    
    The commit mentioned above fixed the test for missing endpoints but
    thereby exposed the other bugs which would now generate null-pointer
    exceptions rather than failed urb submissions.
    
    The regression was introduced in v3.7, but the offending commit was also
    marked for stable.
    
    Reported-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Tested-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 35ec925801ee0b36aa4c2fc658535b777997d146
Author: Tristan Bruns <tristan@tristanbruns.de>
Date:   Sun Apr 13 23:57:16 2014 +0200

    USB: cp210x: Add 8281 (Nanotec Plug & Drive)
    
    commit 72b3007951010ce1bbf950e23b19d9839fa905a5 upstream.
    
    Signed-off-by: Tristan Bruns <tristan@tristanbruns.de>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d9fede04483fa9e0f383403db0bb318f12bda3ea
Author: Michael Ulbricht <michael.ulbricht@systec-electronic.com>
Date:   Tue Mar 25 10:34:18 2014 +0100

    USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver
    
    commit 895d240d1db0b2736d779200788e4c4aea28a0c6 upstream.
    
    By specifying NO_UNION_NORMAL the ACM driver does only use the first two
    USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA
    interfaces are left to the USB serial driver.
    
    Signed-off-by: Michael Ulbricht <michael.ulbricht@systec-electronic.com>
    Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
    Signed-off-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 62b9708fea858a5722aaa15b8ea6a31227f54390
Author: Mel Gorman <mgorman@suse.de>
Date:   Fri Apr 18 15:07:21 2014 -0700

    mm: use paravirt friendly ops for NUMA hinting ptes
    
    commit 29c7787075c92ca8af353acd5301481e6f37082f upstream.
    
    David Vrabel identified a regression when using automatic NUMA balancing
    under Xen whereby page table entries were getting corrupted due to the
    use of native PTE operations.  Quoting him
    
    	Xen PV guest page tables require that their entries use machine
    	addresses if the preset bit (_PAGE_PRESENT) is set, and (for
    	successful migration) non-present PTEs must use pseudo-physical
    	addresses.  This is because on migration MFNs in present PTEs are
    	translated to PFNs (canonicalised) so they may be translated back
    	to the new MFN in the destination domain (uncanonicalised).
    
    	pte_mknonnuma(), pmd_mknonnuma(), pte_mknuma() and pmd_mknuma()
    	set and clear the _PAGE_PRESENT bit using pte_set_flags(),
    	pte_clear_flags(), etc.
    
    	In a Xen PV guest, these functions must translate MFNs to PFNs
    	when clearing _PAGE_PRESENT and translate PFNs to MFNs when setting
    	_PAGE_PRESENT.
    
    His suggested fix converted p[te|md]_[set|clear]_flags to using
    paravirt-friendly ops but this is overkill.  He suggested an alternative
    of using p[te|md]_modify in the NUMA page table operations but this is
    does more work than necessary and would require looking up a VMA for
    protections.
    
    This patch modifies the NUMA page table operations to use paravirt
    friendly operations to set/clear the flags of interest.  Unfortunately
    this will take a performance hit when updating the PTEs on
    CONFIG_PARAVIRT but I do not see a way around it that does not break
    Xen.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: David Vrabel <david.vrabel@citrix.com>
    Tested-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Anvin <hpa@zytor.com>
    Cc: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Steven Noonan <steven@uplinklabs.net>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Cyrill Gorcunov <gorcunov@gmail.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>

commit 4921f0b2e1fc49c368d6fd43bff5bdbd1e48dbb3
Author: Mizuma, Masayoshi <m.mizuma@jp.fujitsu.com>
Date:   Fri Apr 18 15:07:18 2014 -0700

    mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()
    
    commit 7848a4bf51b34f41fcc9bd77e837126d99ae84e3 upstream.
    
    soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892 "mm:
    hugetlb: fix softlockup when a large number of hugepages are freed." can
    happen in return_unused_surplus_pages(), so let's fix it.
    
    Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>

commit 6c662df0d0c0770b92283c45b9566e748812d7b8
Author: NeilBrown <neilb@suse.de>
Date:   Wed Apr 9 12:25:43 2014 +1000

    md/raid1: r1buf_pool_alloc: free allocate pages when subsequent allocation fails.
    
    commit da1aab3dca9aa88ae34ca392470b8943159e25fe upstream.
    
    When performing a user-request check/repair (MD_RECOVERY_REQUEST is set)
    on a raid1, we allocate multiple bios each with their own set of pages.
    
    If the page allocations for one bio fails, we currently do *not* free
    the pages allocated for the previous bios, nor do we free the bio itself.
    
    This patch frees all the already-allocate pages, and makes sure that
    all the bios are freed as well.
    
    This bug can cause a memory leak which can ultimately OOM a machine.
    It was introduced in 3.10-rc1.
    
    Fixes: a07876064a0b73ab5ef1ebcf14b1cf0231c07858
    Cc: Kent Overstreet <koverstreet@google.com>
    Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f0d5a953d2257915fe80ee04f7c9f0e1b021a3ee
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri May 2 19:48:13 2014 +0200

    HID: add NO_INIT_REPORTS quirk for Synaptics Touch Pad V 103S
    
    commit 2f433083e854ec72c19dc9b0e1cebcc8e230fd75 upstream.
    
    This touchpad seriously dislikes init reports, not only timeing out, but
    also refusing to work after this.
    
    Reported-and-tested-by: Vincent Fortier <th0ma7@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3802414792ab9256690acb4897e02102fb4bab67
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Mon Mar 31 13:27:10 2014 -0400

    HID: core: do not scan constant input report
    
    commit e24d0d399b2fce71b627043e900ef28283850482 upstream.
    
    The Microsoft Surface Type/Touch Cover 2 is a fancy device which advertised
    itself as a multitouch device but with constant input reports.
    This way, hid_scan_report() gives the group MULTITOUCH to it, but
    hid-multitouch can not handle it due to the constant collection ignored
    by hid-input.
    
    To prevent such crap in the future, and while we do not fix this particular
    device, make the scan_report coherent with hid-input.c, and ignore constant
    input reports.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 696a8b6ad3ff961ab3530a9adaaa4cb160017231
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Apr 4 14:48:04 2014 -0400

    xen/spinlock: Don't enable them unconditionally.
    
    commit e0fc17a936334c08b2729fff87168c03fdecf5b6 upstream.
    
    The git commit a945928ea2709bc0e8e8165d33aed855a0110279
    ('xen: Do not enable spinlocks before jump_label_init() has executed')
    was added to deal with the jump machinery. Earlier the code
    that turned on the jump label was only called by Xen specific
    functions. But now that it had been moved to the initcall machinery
    it gets called on Xen, KVM, and baremetal - ouch!. And the detection
    machinery to only call it on Xen wasn't remembered in the heat
    of merge window excitement.
    
    This means that the slowpath is enabled on baremetal while it should
    not be.
    
    Reported-by: Waiman Long <waiman.long@hp.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e02f9eff60504d91b778d8bd50ed649d0ab6e2d6
Author: Sachin Prabhu <sprabhu@redhat.com>
Date:   Tue Mar 11 16:11:47 2014 +0000

    cifs: Wait for writebacks to complete before attempting write.
    
    commit c11f1df5003d534fd067f0168bfad7befffb3b5c upstream.
    
    Problem reported in Red Hat bz 1040329 for strict writes where we cache
    only when we hold oplock and write direct to the server when we don't.
    
    When we receive an oplock break, we first change the oplock value for
    the inode in cifsInodeInfo->oplock to indicate that we no longer hold
    the oplock before we enqueue a task to flush changes to the backing
    device. Once we have completed flushing the changes, we return the
    oplock to the server.
    
    There are 2 ways here where we can have data corruption
    1) While we flush changes to the backing device as part of the oplock
    break, we can have processes write to the file. These writes check for
    the oplock, find none and attempt to write directly to the server.
    These direct writes made while we are flushing from cache could be
    overwritten by data being flushed from the cache causing data
    corruption.
    2) While a thread runs in cifs_strict_writev, the machine could receive
    and process an oplock break after the thread has checked the oplock and
    found that it allows us to cache and before we have made changes to the
    cache. In that case, we end up with a dirty page in cache when we
    shouldn't have any. This will be flushed later and will overwrite all
    subsequent writes to the part of the file represented by this page.
    
    Before making any writes to the server, we need to confirm that we are
    not in the process of flushing data to the server and if we are, we
    should wait until the process is complete before we attempt the write.
    We should also wait for existing writes to complete before we process
    an oplock break request which changes oplock values.
    
    We add a version specific  downgrade_oplock() operation to allow for
    differences in the oplock values set for the different smb versions.
    
    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 92e9ead530eccbfcc408c60ddb6d40ec4d952119
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Mar 14 10:56:20 2014 -0400

    don't bother with {get,put}_write_access() on non-regular files
    
    commit dd20908a8a06b22c171f6c3fcdbdbd65bed07505 upstream.
    
    it's pointless and actually leads to wrong behaviour in at least one
    moderately convoluted case (pipe(), close one end, try to get to
    another via /proc/*/fd and run into ETXTBUSY).
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 39760567d0146b23580d41db26b60cd9f873a4df
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Tue Apr 15 10:54:37 2014 +0530

    tick-common: Fix wrong check in tick_check_replacement()
    
    commit 521c42990e9d561ed5ed9f501f07639d0512b3c9 upstream.
    
    tick_check_replacement() returns if a replacement of clock_event_device is
    possible or not. It does this as the first check:
    
    	if (tick_check_percpu(curdev, newdev, smp_processor_id()))
    		return false;
    
    Thats wrong. tick_check_percpu() returns true when the device is
    useable. Check for false instead.
    
    [ tglx: Massaged changelog ]
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: linaro-kernel@lists.linaro.org
    Cc: fweisbec@gmail.com
    Cc: Arvind.Chauhan@arm.com
    Cc: linaro-networking@linaro.org
    Link: http://lkml.kernel.org/r/486a02efe0246635aaba786e24b42d316438bf3b.1397537987.git.viresh.kumar@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6319dbe1fba8a83813b672db8cc4fe4a70906fbd
Author: Ilya Dryomov <ilya.dryomov@inktank.com>
Date:   Tue Mar 4 11:57:17 2014 +0200

    rbd: fix error paths in rbd_img_request_fill()
    
    commit 42dd037c08c7cd6e3e9af7824b0c1d063f838885 upstream.
    
    Doing rbd_obj_request_put() in rbd_img_request_fill() error paths is
    not only insufficient, but also triggers an rbd_assert() in
    rbd_obj_request_destroy():
    
        Assertion failure in rbd_obj_request_destroy() at line 1867:
    
        rbd_assert(obj_request->img_request == NULL);
    
    rbd_img_obj_request_add() adds obj_requests to the img_request, the
    opposite is rbd_img_obj_request_del().  Use it.
    
    Fixes: http://tracker.ceph.com/issues/7327
    
    Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 75dff0a4149fe8aa5dedc19183cd0985c96c49b3
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Feb 26 10:54:36 2014 -0500

    tracepoint: Do not waste memory on mods with no tracepoints
    
    commit 7dec935a3aa04412cba2cebe1524ae0d34a30c24 upstream.
    
    No reason to allocate tp_module structures for modules that have no
    tracepoints. This just wastes memory.
    
    Fixes: b75ef8b44b1c "Tracepoint: Dissociate from module mutex"
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f34728610b2a8c7b9864f9404f2884c17f6fca5c
Author: Thomas Graf <tgraf@suug.ch>
Date:   Fri Apr 4 17:57:45 2014 +0200

    netfilter: Can't fail and free after table replacement
    
    commit c58dd2dd443c26d856a168db108a0cd11c285bf3 upstream.
    
    All xtables variants suffer from the defect that the copy_to_user()
    to copy the counters to user memory may fail after the table has
    already been exchanged and thus exposed. Return an error at this
    point will result in freeing the already exposed table. Any
    subsequent packet processing will result in a kernel panic.
    
    We can't copy the counters before exposing the new tables as we
    want provide the counter state after the old table has been
    unhooked. Therefore convert this into a silent error.
    
    Cc: Florian Westphal <fw@strlen.de>
    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5104b40a981d26212ced149fbd43ad0b6b72910b
Author: Roman Pen <r.peniaev@gmail.com>
Date:   Tue Mar 4 23:13:10 2014 +0900

    blktrace: fix accounting of partially completed requests
    
    commit af5040da01ef980670b3741b3e10733ee3e33566 upstream.
    
    trace_block_rq_complete does not take into account that request can
    be partially completed, so we can get the following incorrect output
    of blkparser:
    
      C   R 232 + 240 [0]
      C   R 240 + 232 [0]
      C   R 248 + 224 [0]
      C   R 256 + 216 [0]
    
    but should be:
    
      C   R 232 + 8 [0]
      C   R 240 + 8 [0]
      C   R 248 + 8 [0]
      C   R 256 + 8 [0]
    
    Also, the whole output summary statistics of completed requests and
    final throughput will be incorrect.
    
    This patch takes into account real completion size of the request and
    fixes wrong completion accounting.
    
    Signed-off-by: Roman Pen <r.peniaev@gmail.com>
    CC: Steven Rostedt <rostedt@goodmis.org>
    CC: Frederic Weisbecker <fweisbec@gmail.com>
    CC: Ingo Molnar <mingo@redhat.com>
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 62c97a8612f753ffa6c5c7bebe140cc0951e539f
Author: Andrey Vagin <avagin@openvz.org>
Date:   Fri Mar 28 13:54:32 2014 +0400

    netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len
    
    commit 223b02d923ecd7c84cf9780bb3686f455d279279 upstream.
    
    "len" contains sizeof(nf_ct_ext) and size of extensions. In a worst
    case it can contain all extensions. Bellow you can find sizes for all
    types of extensions. Their sum is definitely bigger than 256.
    
    nf_ct_ext_types[0]->len = 24
    nf_ct_ext_types[1]->len = 32
    nf_ct_ext_types[2]->len = 24
    nf_ct_ext_types[3]->len = 32
    nf_ct_ext_types[4]->len = 152
    nf_ct_ext_types[5]->len = 2
    nf_ct_ext_types[6]->len = 16
    nf_ct_ext_types[7]->len = 8
    
    I have seen "len" up to 280 and my host has crashes w/o this patch.
    
    The right way to fix this problem is reducing the size of the ecache
    extension (4) and Florian is going to do this, but these changes will
    be quite large to be appropriate for a stable tree.
    
    Fixes: 5b423f6a40a0 (netfilter: nf_conntrack: fix racy timer handling with reliable)
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1eff16e242de6916cdd365655c61b315fa752cc1
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Tue Dec 10 22:10:41 2013 -0500

    audit: convert PPIDs to the inital PID namespace.
    
    commit c92cdeb45eea38515e82187f48c2e4f435fb4e25 upstream.
    
    sys_getppid() returns the parent pid of the current process in its own pid
    namespace.  Since audit filters are based in the init pid namespace, a process
    could avoid a filter or trigger an unintended one by being in an alternate pid
    namespace or log meaningless information.
    
    Switch to task_ppid_nr() for PPIDs to anchor all audit filters in the
    init_pid_ns.
    
    (informed by ebiederman's 6c621b7e)
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 146ca9148a6898ebc57576419dd375ac266f23b2
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Thu Apr 10 18:19:12 2014 -0300

    KVM: x86: remove WARN_ON from get_kernel_ns()
    
    commit b351c39cc9e0151cee9b8d52a1e714928faabb38 upstream.
    
    Function and callers can be preempted.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=73721
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ef57e93eaa37b483191b5949b816d22ae441b45a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 30 20:13:51 2013 +0300

    SCSI: megaraid: missing bounds check in mimd_to_kioc()
    
    commit 3de2260140417759c669d391613d583baf03b0cf upstream.
    
    pthru32->dataxferlen comes from the user so we need to check that it's
    not too large so we don't overflow the buffer.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Sumit Saxena <sumit.saxena@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 40e27bd1b33c703c9b5ba66fc1c4f98419490727
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Tue Jan 21 07:01:41 2014 -0800

    SCSI: dual scan thread bug fix
    
    commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.
    
    In the highly unusual case where two threads are running concurrently through
    the scanning code scanning the same target, we run into the situation where
    one may allocate the target while the other is still using it.  In this case,
    because the reap checks for STARGET_CREATED and kills the target without
    reference counting, the second thread will do the wrong thing on reap.
    
    Fix this by reference counting even creates and doing the STARGET_CREATED
    check in the final put.
    
    Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b51845d41c715e18ffbb413da213e72667e852ec
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Tue Jan 21 07:00:50 2014 -0800

    scsi: fix our current target reap infrastructure
    
    commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.
    
    This patch eliminates the reap_ref and replaces it with a proper kref.
    On last put of this kref, the target is removed from visibility in
    sysfs.  The final call to scsi_target_reap() for the device is done from
    __scsi_remove_device() and only if the device was made visible.  This
    ensures that the target disappears as soon as the last device is gone
    rather than waiting until final release of the device (which is often
    too long).
    
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 99565b6c9eb1ae28ab633d7104e654e6dc6a6679
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Nov 12 15:10:01 2013 -0800

    list: introduce list_next_entry() and list_prev_entry()
    
    commit 008208c6b26f21c2648c250a09c55e737c02c5f8 upstream.
    
    Add two trivial helpers list_next_entry() and list_prev_entry(), they
    can have a lot of users including list.h itself.  In fact the 1st one is
    already defined in events/core.c and bnx2x_sp.c, so the patch simply
    moves the definition to list.h.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Eilon Greenstein <eilong@broadcom.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    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>

commit 87344d15c7c16a64687365a73f62422ffa853545
Author: Aleksander Morgado <aleksander@aleksander.es>
Date:   Wed Feb 12 15:55:14 2014 +0100

    net: qmi_wwan: add support for Cinterion PXS8 and PHS8
    
    commit 9b2b6a2d669c909dd0b125fc834da94bcfc0aee7 upstream.
    
    When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a
    QMI port and a WWAN interface.
    
    CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
    CC: Christian Schmiedl <christian.schmiedl@gemalto.com>
    CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com>
    CC: David McCullough <david.mccullough@accelecon.com>
    Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 341bc61c767602bd9f696094d047702e1fbcc26a
Author: Raymond Wanyoike <raymond.wanyoike@gmail.com>
Date:   Sun Feb 9 00:01:02 2014 +0300

    net: qmi_wwan: add ZTE MF667
    
    commit 7653aabfbdc73c1567e29a9790701f5898ba1420 upstream.
    
    The driver description files give these descriptions to the vendor specific
    ports on this modem:
    
     VID_19D2&PID_1270&MI_00: "ZTE MF667 Diagnostics Port"
     VID_19D2&PID_1270&MI_01: "ZTE MF667 AT Port"
     VID_19D2&PID_1270&MI_02: "ZTE MF667 ATExt2 Port"
     VID_19D2&PID_1270&MI_03: "ZTE MF667 ATExt Port"
     VID_19D2&PID_1270&MI_04: "ZTE MF667 USB Modem"
     VID_19D2&PID_1270&MI_05: "ZTE MF667 Network Adapter"
    
    Signed-off-by: Raymond Wanyoike <raymond.wanyoike@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7e50c39ff5e62755a9999f84eff8d2c1a7d6a07b
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Wed Sep 25 11:21:25 2013 +0200

    net: qmi_wwan: add Telit LE920 newer firmware support
    
    commit 905468fa4d54c3e572ed3045cd47cce37780716e upstream.
    
    Newer firmware use a new pid and a different interface.
    
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a1c6804ab9dc4e83633c6fb9ce4cdc88d6c8d016
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:42:43 2014 -0500

    tgafb: fix mode setting with fbset
    
    commit 624966589041deb32a2626ee2e176e8274581101 upstream.
    
    Mode setting in the TGA driver is broken for these reasons:
    
    - info->fix.line_length is set just once in tgafb_init_fix function. If
      we change videomode, info->fix.line_length is not recalculated - so
      the video mode is changed but the screen is corrupted because of wrong
      info->fix.line_length.
    
    - info->fix.smem_len is set in tgafb_init_fix to the size of the default
      video mode (640x480). If we set a higher resolution,
      info->fix.smem_len is smaller than the current screen size, preventing
      the userspace program from mapping the framebuffer.
    
    This patch fixes it:
    
    - info->fix.line_length initialization is moved to tgafb_set_par so that
      it is recalculated with each mode change.
    
    - info->fix.smem_len is set to a fixed value representing the real
      amount of video ram (the values are taken from xfree86 driver).
    
    - add a check to tgafb_check_var to prevent us from setting a videomode
      that doesn't fit into videoram.
    
    - in tgafb_register, tgafb_init_fix is moved upwards, to be called
      before fb_find_mode (because fb_find_mode already needs the videoram
      size set in tgafb_init_fix).
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vga.kernel.org
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 67ded0151926a7721f71ba86cec60ca8ce6f072e
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Sun Mar 16 14:00:19 2014 -0400

    sched: declare pid_alive as inline
    
    commit 80e0b6e8a001361316a2d62b748fe677ec46b860 upstream.
    
    We accidentally declared pid_alive without any extern/inline connotation.
    Some platforms were fine with this, some like ia64 and mips were very angry.
    If the function is inline, the prototype should be inline!
    
    on ia64:
    include/linux/sched.h:1718: warning: 'pid_alive' declared inline after
    being called
    
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 363e9b002420dd6bf728e558d82f49a2e077e9c5
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Thu Aug 15 18:05:12 2013 -0400

    pid: get pid_t ppid of task in init_pid_ns
    
    commit ad36d28293936b03d6b7996e9d6aadfd73c0eb08 upstream.
    
    Added the functions task_ppid_nr_ns() and task_ppid_nr() to abstract the lookup
    of the PPID (real_parent's pid_t) of a process, including rcu locking, in the
    arbitrary and init_pid_ns.
    This provides an alternative to sys_getppid(), which is relative to the child
    process' pid namespace.
    
    (informed by ebiederman's 6c621b7e)
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0da837ca84b26c3c4f560788a6e62b12d345e49f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Oct 4 00:29:47 2013 +0200

    xhci: For streams the css flag most be read from the stream-ctx on ep stop
    
    commit c4bedb77ec4cb42f37cae4cbfddda8283161f7c8 upstream.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit aea22946135c7373d20d12d7c16470679b4c7455
Author: Yufeng Shen <miletus@chromium.org>
Date:   Mon Jan 27 18:02:46 2014 -0500

    HID: usbhid: quirk for CY-TM75 75 inch Touch Overlay
    
    commit 29191039e21f66e204acffed63c486674a1918bd upstream.
    
    There is timeout error during initialization:
    kernel: [   11.733104] hid-multitouch 0003:1870:0110.0001: usb_submit_urb(ctrl) failed: -1
    kernel: [   11.734093] hid-multitouch 0003:1870:0110.0001: timeout initializing reports
    
    Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
    
    Signed-off-by: Yufeng Shen <miletus@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 50b058b07dfb457304baffd7770370558f5fad44
Author: Emanuel Krenz <emanuelkrenz@web.de>
Date:   Fri Dec 13 14:51:53 2013 +0100

    HID: add support for SiS multitouch panel in the touch monitor LG 23ET83V
    
    commit 954bb3da814e794f546f55449c508299a127fef8 upstream.
    
    [jkosina@suse.cz: refresh to apply after SIS quirk merging]
    Signed-off-by: Emanuel Krenz <emanuelkrenz@web.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cc54585cd1f345dd07e73d48605d29c2f06388c2
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Nov 27 10:05:58 2013 +0800

    HID: usbhid: quirk for Synaptics Quad HD touchscreen
    
    commit 12f508aede4bda5d20a2dd3ff3deb16ef47a97e9 upstream.
    
    Add Synaptics HD touchscreen(06cb:1ac3) to no init report quirk
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c0ceae2e7e385aa13b823a978b39226850f001ef
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Nov 27 10:05:57 2013 +0800

    HID: usbhid: quirk for Synaptics HD touchscreen
    
    commit d8e2e7581d2521910398c4c80d7a3b78e84da7d5 upstream.
    
    Add Synaptics HD touchscreen(06cb:0ac3) to no init report quirk.
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 08da1b36cb0452b489657a0164db12fd3d44c273
Author: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Date:   Mon Dec 2 23:19:24 2013 +0800

    HID: usbhid: fix sis quirk
    
    commit 6d16e9c301290268b92ce3d48114f982e9c4b00a upstream.
    
    Since commit 765e5fbd merged the sis quirk,
    then USB_VENDOR_ID_SIS2_TOUCH remains undefined.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f49f5d56ccdeeccd1f3a245edbf189e5dc83f9eb
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Nov 27 10:05:56 2013 +0800

    HID: usbhid: merge the sis quirk
    
    commit 765e5fbd3e04ba753b2585e9f852fdcd34b95d10 upstream.
    
    USB_VENDOR_ID_SIS and USB_VENDOR_ID_SIS2_TOUCH are identical,
    so refine the code and merge the quirks.
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5872d5558f8b2e001207dd558a2a5f6327d54ed9
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Mon Jul 15 10:23:11 2013 -0400

    audit: restore order of tty and ses fields in log output
    
    commit 2f2ad1013322c8f6c40fc6dafdbd32442fa730ad upstream.
    
    When being refactored from audit_log_start() to audit_log_task_info(), in
    commit e23eb920 the tty and ses fields in the log output got transposed.
    Restore to original order to avoid breaking search tools.
    
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bcbac220dab16a4038ac1a7c5cfe3e7f034b3836
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Mon Dec 30 15:31:17 2013 +0100

    powerpc: Add vr save/restore functions
    
    commit 8fe9c93e7453e67b8bd09f263ec1bb0783c733fc upstream.
    
    GCC 4.8 now generates out-of-line vr save/restore functions when
    optimizing for size.  They are needed for the raid6 altivec support.
    
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>