commit ae74a22cb5024a22753c3bb5c7d4036db1929fc0
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Oct 17 09:21:14 2014 +0200

    Linux 3.12.31

commit bc355676ca09ef8f4a5461b85048c86a65fd5594
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date:   Tue Sep 23 01:21:11 2014 +0100

    serial: 8250: Add Quark X1000 to 8250_pci.c
    
    commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream.
    
    Quark X1000 contains two designware derived 8250 serial ports.
    Each port has a unique PCI configuration space consisting of
    BAR0:UART BAR1:DMA respectively.
    
    Unlike the standard 8250 the register width is 32 bits for RHR,IER etc
    The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a
    bitrate of up to about 2.76 megabits per second.
    
    This patch enables standard 8250 mode
    
    Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 78f2e03927bc88caf2cfa456b46e3dfda4426f19
Author: Andreas Bomholtz <andreas@seluxit.com>
Date:   Mon Sep 22 09:50:43 2014 +0200

    USB: cp210x: add support for Seluxit USB dongle
    
    commit dee80ad12d2b1b304286a707fde7ab05d1fc7bab upstream.
    
    Added the Seluxit ApS USB Serial Dongle to cp210x driver.
    
    Signed-off-by: Andreas Bomholtz <andreas@seluxit.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dcda24aacd001dce3aeac3e40b07ca67994fcb25
Author: Joe Savage <joe.savage@goketra.com>
Date:   Sat Sep 20 08:01:16 2014 -0500

    USB: serial: cp210x: added Ketra N1 wireless interface support
    
    commit bfc2d7dfdd761ae3beccdb26abebe03cef042f46 upstream.
    
    Added support for Ketra N1 wireless interface, which uses the
    Silicon Labs' CP2104 USB to UART bridge with customized PID 8946.
    
    Signed-off-by: Joe Savage <joe.savage@goketra.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8e31d92283137b20589204cb0ebb77f90fa38a23
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Fri Sep 19 10:13:50 2014 +0800

    USB: Add device quirk for ASUS T100 Base Station keyboard
    
    commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 upstream.
    
    This full-speed USB device generates spurious remote wakeup event
    as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
    Linux can't enter system suspend and S0ix power saving modes once
    this keyboard is used.
    
    This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
    With this quirk set, wakeup capability will be ignored during
    device configure.
    
    This patch could be back-ported to kernels as old as 2.6.39.
    
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d24c1c0f7c31c89465ab1df21bd9fcbe0c6c59ac
Author: Per Hurtig <per.hurtig@kau.se>
Date:   Thu Jun 12 17:08:32 2014 +0200

    tcp: fixing TLP's FIN recovery
    
    [ Upstream commit bef1909ee3ed1ca39231b260a8d3b4544ecd0c8f ]
    
    Fix to a problem observed when losing a FIN segment that does not
    contain data.  In such situations, TLP is unable to recover from
    *any* tail loss and instead adds at least PTO ms to the
    retransmission process, i.e., RTO = RTO + PTO.
    
    Signed-off-by: Per Hurtig <per.hurtig@kau.se>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Nandita Dukkipati <nanditad@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 e6fd6243cdc7434e7001589099394321a1670b47
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Fri Oct 3 18:16:20 2014 -0400

    sctp: handle association restarts when the socket is closed.
    
    [ Upstream commit bdf6fa52f01b941d4a80372d56de465bdbbd1d23 ]
    
    Currently association restarts do not take into consideration the
    state of the socket.  When a restart happens, the current assocation
    simply transitions into established state.  This creates a condition
    where a remote system, through a the restart procedure, may create a
    local association that is no way reachable by user.  The conditions
    to trigger this are as follows:
      1) Remote does not acknoledge some data causing data to remain
         outstanding.
      2) Local application calls close() on the socket.  Since data
         is still outstanding, the association is placed in SHUTDOWN_PENDING
         state.  However, the socket is closed.
      3) The remote tries to create a new association, triggering a restart
         on the local system.  The association moves from SHUTDOWN_PENDING
         to ESTABLISHED.  At this point, it is no longer reachable by
         any socket on the local system.
    
    This patch addresses the above situation by moving the newly ESTABLISHED
    association into SHUTDOWN-SENT state and bundling a SHUTDOWN after
    the COOKIE-ACK chunk.  This way, the restarted associate immidiately
    enters the shutdown procedure and forces the termination of the
    unreachable association.
    
    Reported-by: David Laight <David.Laight@aculab.com>
    Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0df5b80cd4590d4fee99341a0c8af0a7997dd490
Author: Joe Lawrence <Joe.Lawrence@stratus.com>
Date:   Fri Oct 3 09:58:34 2014 -0400

    team: avoid race condition in scheduling delayed work
    
    [ Upstream commit 47549650abd13d873fd2e5fc218db19e21031074 ]
    
    When team_notify_peers and team_mcast_rejoin are called, they both reset
    their respective .count_pending atomic variable. Then when the actual
    worker function is executed, the variable is atomically decremented.
    This pattern introduces a potential race condition where the
    .count_pending rolls over and the worker function keeps rescheduling
    until .count_pending decrements to zero again:
    
    THREAD 1                           THREAD 2
    
    ========                           ========
    team_notify_peers(teamX)
      atomic_set count_pending = 1
      schedule_delayed_work
                                       team_notify_peers(teamX)
                                       atomic_set count_pending = 1
    team_notify_peers_work
      atomic_dec_and_test
        count_pending = 0
      (return)
                                       schedule_delayed_work
                                       team_notify_peers_work
                                       atomic_dec_and_test
                                         count_pending = -1
                                       schedule_delayed_work
                                       (repeat until count_pending = 0)
    
    Instead of assigning a new value to .count_pending, use atomic_add to
    tack-on the additional desired worker function invocations.
    
    Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
    Acked-by: Jiri Pirko <jiri@resnulli.us>
    Fixes: fc423ff00df3a19554414ee ("team: add peer notification")
    Fixes: 492b200efdd20b8fcfdac87 ("team: add support for sending multicast rejoins")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9865479b5052f0500970ac999c4e9eba41926665
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Thu Oct 2 18:26:49 2014 +0200

    ip6_gre: fix flowi6_proto value in xmit path
    
    [ Upstream commit 3be07244b7337760a3269d56b2f4a63e72218648 ]
    
    In xmit path, we build a flowi6 which will be used for the output route lookup.
    We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the
    protocol should be IPPROTO_GRE.
    
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Reported-by: Matthieu Ternisien d'Ouville <matthieu.tdo@6wind.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 4d7fe752478f96bcdf0d54d077e98733ff6a07a9
Author: KY Srinivasan <kys@microsoft.com>
Date:   Sun Sep 28 22:16:43 2014 -0700

    hyperv: Fix a bug in netvsc_start_xmit()
    
    [ Upstream commit dedb845ded56ded1c62f5398a94ffa8615d4592d ]
    
    After the packet is successfully sent, we should not touch the skb
    as it may have been freed. This patch is based on the work done by
    Long Li <longli@microsoft.com>.
    
    In this version of the patch I have fixed issues pointed out by David.
    David, please queue this up for stable.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Tested-by: Long Li <longli@microsoft.com>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3473692f7cd31b6fd424fb282e12bcd94c8c6ddc
Author: Soren Brinkmann <soren.brinkmann@xilinx.com>
Date:   Mon Sep 22 16:49:08 2014 -0700

    Revert "net/macb: add pinctrl consumer support"
    
    [ Upstream commit 9026968abe7ad102f4ac5c6d96d733643f75399c ]
    
    This reverts commit 8ef29f8aae524bd51298fb10ac6a5ce6c4c5a3d8.
    The driver core already calls pinctrl_get() and claims the default
    state. There is no need to replicate this in the driver.
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 34596a866103f99702a0fd2b89f25da063a886fa
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Mon Sep 22 16:34:17 2014 -0400

    macvtap: Fix race between device delete and open.
    
    [ Upstream commit 40b8fe45d1f094e3babe7b2dc2b71557ab71401d ]
    
    In macvtap device delete and open calls can race and
    this causes a list curruption of the vlan queue_list.
    
    The race intself is triggered by the idr accessors
    that located the vlan device.  The device is stored
    into and removed from the idr under both an rtnl and
    a mutex.  However, when attempting to locate the device
    in idr, only a mutex is taken.  As a result, once cpu
    perfoming a delete may take an rtnl and wait for the mutex,
    while another cput doing an open() will take the idr
    mutex first to fetch the device pointer and later take
    an rtnl to add a queue for the device which may have
    just gotten deleted.
    
    With this patch, we now hold the rtnl for the duration
    of the macvtap_open() call thus making sure that
    open will not race with delete.
    
    CC: Michael S. Tsirkin <mst@redhat.com>
    CC: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2a9e5d6b68e0d88843caeeb69944e17c632f8a73
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Sep 16 10:08:49 2014 +0200

    xfrm: Generate queueing routes only from route lookup functions
    
    [ Upstream commit b8c203b2d2fc961bafd53b41d5396bbcdec55998 ]
    
    Currently we genarate a queueing route if we have matching policies
    but can not resolve the states and the sysctl xfrm_larval_drop is
    disabled. Here we assume that dst_output() is called to kill the
    queued packets. Unfortunately this assumption is not true in all
    cases, so it is possible that these packets leave the system unwanted.
    
    We fix this by generating queueing routes only from the
    route lookup functions, here we can guarantee a call to
    dst_output() afterwards.
    
    Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue")
    Reported-by: Konstantinos Kolelis <k.kolelis@sirrix.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e5a51bbc5bacc7131a8ff04412468a0517dbb2b2
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Sep 16 10:08:40 2014 +0200

    xfrm: Generate blackhole routes only from route lookup functions
    
    [ Upstream commit f92ee61982d6da15a9e49664ecd6405a15a2ee56 ]
    
    Currently we genarate a blackhole route route whenever we have
    matching policies but can not resolve the states. Here we assume
    that dst_output() is called to kill the balckholed packets.
    Unfortunately this assumption is not true in all cases, so
    it is possible that these packets leave the system unwanted.
    
    We fix this by generating blackhole routes only from the
    route lookup functions, here we can guarantee a call to
    dst_output() afterwards.
    
    Fixes: 2774c131b1d ("xfrm: Handle blackhole route creation via afinfo.")
    Reported-by: Konstantinos Kolelis <k.kolelis@sirrix.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d8cff32f227e9c50347a76deae7d71302950580f
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Tue Sep 30 19:39:36 2014 -0400

    tg3: Allow for recieve of full-size 8021AD frames
    
    [ Upstream commit 7d3083ee36b51e425b6abd76778a2046906b0fd3 ]
    
    When receiving a vlan-tagged frame that still contains
    a vlan header, the length of the packet will be greater
    then MTU+ETH_HLEN since it will account of the extra
    vlan header.  TG3 checks this for the case for 802.1Q,
    but not for 802.1ad.  As a result, full sized 802.1ad
    frames get dropped by the card.
    
    Add a check for 802.1ad protocol when receving full
    sized frames.
    
    Suggested-by: Prashant Sreedharan <prashant@broadcom.com>
    CC: Prashant Sreedharan <prashant@broadcom.com>
    CC: Michael Chan <mchan@broadcom.com>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1042464ee3e7c833b24859a62943d351ccf66cad
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Thu Sep 18 10:31:17 2014 -0400

    tg3: Work around HW/FW limitations with vlan encapsulated frames
    
    [ Upstream commit 476c18850c6cbaa3f2bb661ae9710645081563b9 ]
    
    TG3 appears to have an issue performing TSO and checksum offloading
    correclty when the frame has been vlan encapsulated (non-accelrated).
    In these cases, tcp checksum is not correctly updated.
    
    This patch attempts to work around this issue.  After the patch,
    802.1ad vlans start working correctly over tg3 devices.
    
    CC: Prashant Sreedharan <prashant@broadcom.com>
    CC: Michael Chan <mchan@broadcom.com>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 77bd83323c2423d2f42bacc2140923860e269af9
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Mon Sep 15 15:24:26 2014 -0400

    bridge: Fix br_should_learn to check vlan_enabled
    
    [ Upstream commit c095f248e63ada504dd90c90baae673ae10ee3fe ]
    
    As Toshiaki Makita pointed out, the BRIDGE_INPUT_SKB_CB will
    not be initialized in br_should_learn() as that function
    is called only from br_handle_local_finish().  That is
    an input handler for link-local ethernet traffic so it perfectly
    correct to check br->vlan_enabled here.
    
    Reported-by: Toshiaki Makita<toshiaki.makita1@gmail.com>
    Fixes: 20adfa1 bridge: Check if vlan filtering is enabled only once.
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6266beeee8158338a894b2ab3a477424e9631696
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Fri Sep 12 16:26:16 2014 -0400

    bridge: Check if vlan filtering is enabled only once.
    
    [ Upstream commit 20adfa1a81af00bf2027644507ad4fa9cd2849cf ]
    
    The bridge code checks if vlan filtering is enabled on both
    ingress and egress.   When the state flip happens, it
    is possible for the bridge to currently be forwarding packets
    and forwarding behavior becomes non-deterministic.  Bridge
    may drop packets on some interfaces, but not others.
    
    This patch solves this by caching the filtered state of the
    packet into skb_cb on ingress.  The skb_cb is guaranteed to
    not be over-written between the time packet entres bridge
    forwarding path and the time it leaves it.  On egress, we
    can then check the cached state to see if we need to
    apply filtering information.
    
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 048b4e83910547178851bef4c47cf40d015ad9eb
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Sep 3 14:12:55 2014 +0200

    l2tp: fix race while getting PMTU on PPP pseudo-wire
    
    [ Upstream commit eed4d839b0cdf9d84b0a9bc63de90fd5e1e886fb ]
    
    Use dst_entry held by sk_dst_get() to retrieve tunnel's PMTU.
    
    The dst_mtu(__sk_dst_get(tunnel->sock)) call was racy. __sk_dst_get()
    could return NULL if tunnel->sock->sk_dst_cache was reset just before the
    call, thus making dst_mtu() dereference a NULL pointer:
    
    [ 1937.661598] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    [ 1937.664005] IP: [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
    [ 1937.664005] PGD daf0c067 PUD d9f93067 PMD 0
    [ 1937.664005] Oops: 0000 [#1] SMP
    [ 1937.664005] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables udp_tunnel pppoe pppox ppp_generic slhc deflate ctr twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common blowfish_generic blowfish_x86_64 blowfish_common des_generic cbc xcbc rmd160 sha512_generic hmac crypto_null af_key xfrm_algo 8021q garp bridge stp llc tun atmtcp clip atm ext3 mbcache jbd iTCO_wdt coretemp kvm_intel iTCO_vendor_support kvm pcspkr evdev ehci_pci lpc_ich mfd_core i5400_edac edac_core i5k_amb shpchp button processor thermal_sys xfs crc32c_generic libcrc32c dm_mod usbhid sg hid sr_mod sd_mod cdrom crc_t10dif crct10dif_common ata_generic ahci ata_piix tg3 libahci libata uhci_hcd ptp ehci_hcd pps_core usbcore scsi_mod libphy usb_common [last unloaded: l2tp_core]
    [ 1937.664005] CPU: 0 PID: 10022 Comm: l2tpstress Tainted: G           O   3.17.0-rc1 #1
    [ 1937.664005] Hardware name: HP ProLiant DL160 G5, BIOS O12 08/22/2008
    [ 1937.664005] task: ffff8800d8fda790 ti: ffff8800c43c4000 task.ti: ffff8800c43c4000
    [ 1937.664005] RIP: 0010:[<ffffffffa049db88>]  [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
    [ 1937.664005] RSP: 0018:ffff8800c43c7de8  EFLAGS: 00010282
    [ 1937.664005] RAX: ffff8800da8a7240 RBX: ffff8800d8c64600 RCX: 000001c325a137b5
    [ 1937.664005] RDX: 8c6318c6318c6320 RSI: 000000000000010c RDI: 0000000000000000
    [ 1937.664005] RBP: ffff8800c43c7ea8 R08: 0000000000000000 R09: 0000000000000000
    [ 1937.664005] R10: ffffffffa048e2c0 R11: ffff8800d8c64600 R12: ffff8800ca7a5000
    [ 1937.664005] R13: ffff8800c439bf40 R14: 000000000000000c R15: 0000000000000009
    [ 1937.664005] FS:  00007fd7f610f700(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
    [ 1937.664005] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 1937.664005] CR2: 0000000000000020 CR3: 00000000d9d75000 CR4: 00000000000027e0
    [ 1937.664005] Stack:
    [ 1937.664005]  ffffffffa049da80 ffff8800d8fda790 000000000000005b ffff880000000009
    [ 1937.664005]  ffff8800daf3f200 0000000000000003 ffff8800c43c7e48 ffffffff81109b57
    [ 1937.664005]  ffffffff81109b0e ffffffff8114c566 0000000000000000 0000000000000000
    [ 1937.664005] Call Trace:
    [ 1937.664005]  [<ffffffffa049da80>] ? pppol2tp_connect+0x235/0x41e [l2tp_ppp]
    [ 1937.664005]  [<ffffffff81109b57>] ? might_fault+0x9e/0xa5
    [ 1937.664005]  [<ffffffff81109b0e>] ? might_fault+0x55/0xa5
    [ 1937.664005]  [<ffffffff8114c566>] ? rcu_read_unlock+0x1c/0x26
    [ 1937.664005]  [<ffffffff81309196>] SYSC_connect+0x87/0xb1
    [ 1937.664005]  [<ffffffff813e56f7>] ? sysret_check+0x1b/0x56
    [ 1937.664005]  [<ffffffff8107590d>] ? trace_hardirqs_on_caller+0x145/0x1a1
    [ 1937.664005]  [<ffffffff81213dee>] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [ 1937.664005]  [<ffffffff8114c262>] ? spin_lock+0x9/0xb
    [ 1937.664005]  [<ffffffff813092b4>] SyS_connect+0x9/0xb
    [ 1937.664005]  [<ffffffff813e56d2>] system_call_fastpath+0x16/0x1b
    [ 1937.664005] Code: 10 2a 84 81 e8 65 76 bd e0 65 ff 0c 25 10 bb 00 00 4d 85 ed 74 37 48 8b 85 60 ff ff ff 48 8b 80 88 01 00 00 48 8b b8 10 02 00 00 <48> 8b 47 20 ff 50 20 85 c0 74 0f 83 e8 28 89 83 10 01 00 00 89
    [ 1937.664005] RIP  [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
    [ 1937.664005]  RSP <ffff8800c43c7de8>
    [ 1937.664005] CR2: 0000000000000020
    [ 1939.559375] ---[ end trace 82d44500f28f8708 ]---
    
    Fixes: f34c4a35d879 ("l2tp: take PMTU from tunnel UDP socket")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    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 bfe32d547264afb5d989d4890249326ba8ce5933
Author: Gerhard Stenzel <gstenzel@linux.vnet.ibm.com>
Date:   Fri Aug 22 21:34:16 2014 +0200

    vxlan: fix incorrect initializer in union vxlan_addr
    
    [ Upstream commit a45e92a599e77ee6a850eabdd0141633fde03915 ]
    
    The first initializer in the following
    
            union vxlan_addr ipa = {
                .sin.sin_addr.s_addr = tip,
                .sa.sa_family = AF_INET,
            };
    
    is optimised away by the compiler, due to the second initializer,
    therefore initialising .sin.sin_addr.s_addr always to 0.
    This results in netlink messages indicating a L3 miss never contain the
    missed IP address. This was observed with GCC 4.8 and 4.9. I do not know about previous versions.
    The problem affects user space programs relying on an IP address being
    sent as part of a netlink message indicating a L3 miss.
    
    Changing
                .sa.sa_family = AF_INET,
    to
                .sin.sin_family = AF_INET,
    fixes the problem.
    
    Signed-off-by: Gerhard Stenzel <gerhard.stenzel@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ddc07cc3af29477df691ed5d87a52c867c0f9b23
Author: Jiri Benc <jbenc@redhat.com>
Date:   Thu Aug 21 21:33:44 2014 +0200

    openvswitch: fix panic with multiple vlan headers
    
    [ Upstream commit 2ba5af42a7b59ef01f9081234d8855140738defd ]
    
    When there are multiple vlan headers present in a received frame, the first
    one is put into vlan_tci and protocol is set to ETH_P_8021Q. Anything in the
    skb beyond the VLAN TPID may be still non-linear, including the inner TCI
    and ethertype. While ovs_flow_extract takes care of IP and IPv6 headers, it
    does nothing with ETH_P_8021Q. Later, if OVS_ACTION_ATTR_POP_VLAN is
    executed, __pop_vlan_tci pulls the next vlan header into vlan_tci.
    
    This leads to two things:
    
    1. Part of the resulting ethernet header is in the non-linear part of the
       skb. When eth_type_trans is called later as the result of
       OVS_ACTION_ATTR_OUTPUT, kernel BUGs in __skb_pull. Also, __pop_vlan_tci
       is in fact accessing random data when it reads past the TPID.
    
    2. network_header points into the ethernet header instead of behind it.
       mac_len is set to a wrong value (10), too.
    
    Reported-by: Yulong Pei <ypei@redhat.com>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c7c834d3b698e1fbac1b4116ae2cfd4b1011d44b
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Aug 15 09:16:04 2014 -0700

    packet: handle too big packets for PACKET_V3
    
    [ Upstream commit dc808110bb62b64a448696ecac3938902c92e1ab ]
    
    af_packet can currently overwrite kernel memory by out of bound
    accesses, because it assumed a [new] block can always hold one frame.
    
    This is not generally the case, even if most existing tools do it right.
    
    This patch clamps too long frames as API permits, and issue a one time
    error on syslog.
    
    [  394.357639] tpacket_rcv: packet too big, clamped from 5042 to 3966. macoff=82
    
    In this example, packet header tp_snaplen was set to 3966,
    and tp_len was set to 5042 (skb->len)
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
    Acked-by: Daniel Borkmann <dborkman@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 5344ad02ec49d76ab81f0f1b9bf84d85c862c202
Author: Neal Cardwell <ncardwell@google.com>
Date:   Thu Aug 14 16:13:07 2014 -0400

    tcp: fix ssthresh and undo for consecutive short FRTO episodes
    
    [ Upstream commit 0c9ab09223fe9922baeb22546c9a90d774a4bde6 ]
    
    Fix TCP FRTO logic so that it always notices when snd_una advances,
    indicating that any RTO after that point will be a new and distinct
    loss episode.
    
    Previously there was a very specific sequence that could cause FRTO to
    fail to notice a new loss episode had started:
    
    (1) RTO timer fires, enter FRTO and retransmit packet 1 in write queue
    (2) receiver ACKs packet 1
    (3) FRTO sends 2 more packets
    (4) RTO timer fires again (should start a new loss episode)
    
    The problem was in step (3) above, where tcp_process_loss() returned
    early (in the spot marked "Step 2.b"), so that it never got to the
    logic to clear icsk_retransmits. Thus icsk_retransmits stayed
    non-zero. Thus in step (4) tcp_enter_loss() would see the non-zero
    icsk_retransmits, decide that this RTO is not a new episode, and
    decide not to cut ssthresh and remember the current cwnd and ssthresh
    for undo.
    
    There were two main consequences to the bug that we have
    observed. First, ssthresh was not decreased in step (4). Second, when
    there was a series of such FRTO (1-4) sequences that happened to be
    followed by an FRTO undo, we would restore the cwnd and ssthresh from
    before the entire series started (instead of the cwnd and ssthresh
    from before the most recent RTO). This could result in cwnd and
    ssthresh being restored to values much bigger than the proper values.
    
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8e2aadd34bfee8db9253431c3c8e5457c130f608
Author: Neal Cardwell <ncardwell@google.com>
Date:   Thu Aug 14 12:40:05 2014 -0400

    tcp: fix tcp_release_cb() to dispatch via address family for mtu_reduced()
    
    [ Upstream commit 4fab9071950c2021d846e18351e0f46a1cffd67b ]
    
    Make sure we use the correct address-family-specific function for
    handling MTU reductions from within tcp_release_cb().
    
    Previously AF_INET6 sockets were incorrectly always using the IPv6
    code path when sometimes they were handling IPv4 traffic and thus had
    an IPv4 dst.
    
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Diagnosed-by: Willem de Bruijn <willemb@google.com>
    Fixes: 563d34d057862 ("tcp: dont drop MTU reduction indications")
    Reviewed-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 38268e2e74140bd50aa3ab982f0579c075975c87
Author: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date:   Thu Aug 14 15:27:20 2014 +0300

    sit: Fix ipip6_tunnel_lookup device matching criteria
    
    [ Upstream commit bc8fc7b8f825ef17a0fb9e68c18ce94fa66ab337 ]
    
    As of 4fddbf5d78 ("sit: strictly restrict incoming traffic to tunnel link device"),
    when looking up a tunnel, tunnel's underlying interface (t->parms.link)
    is verified to match incoming traffic's ingress device.
    
    However the comparison was incorrectly based on skb->dev->iflink.
    
    Instead, dev->ifindex should be used, which correctly represents the
    interface from which the IP stack hands the ipip6 packets.
    
    This allows setting up sit tunnels bound to vlan interfaces (otherwise
    incoming ipip6 traffic on the vlan interface was dropped due to
    ipip6_tunnel_lookup match failure).
    
    Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
    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 e6db6e560b19b58d075fbb398c5086444d6cd837
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Aug 12 10:35:19 2014 +0200

    myri10ge: check for DMA mapping errors
    
    [ Upstream commit 10545937e866ccdbb7ab583031dbdcc6b14e4eb4 ]
    
    On IOMMU systems DMA mapping can fail, we need to check for
    that possibility.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f55ef858b1beb467609805086a18a0e91857e577
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Fri Aug 8 14:42:13 2014 -0400

    net: Always untag vlan-tagged traffic on input.
    
    [ Upstream commit 0d5501c1c828fb97d02af50aa9d2b1a5498b94e4 ]
    
    Currently the functionality to untag traffic on input resides
    as part of the vlan module and is build only when VLAN support
    is enabled in the kernel.  When VLAN is disabled, the function
    vlan_untag() turns into a stub and doesn't really untag the
    packets.  This seems to create an interesting interaction
    between VMs supporting checksum offloading and some network drivers.
    
    There are some drivers that do not allow the user to change
    tx-vlan-offload feature of the driver.  These drivers also seem
    to assume that any VLAN-tagged traffic they transmit will
    have the vlan information in the vlan_tci and not in the vlan
    header already in the skb.  When transmitting skbs that already
    have tagged data with partial checksum set, the checksum doesn't
    appear to be updated correctly by the card thus resulting in a
    failure to establish TCP connections.
    
    The following is a packet trace taken on the receiver where a
    sender is a VM with a VLAN configued.  The host VM is running on
    doest not have VLAN support and the outging interface on the
    host is tg3:
    10:12:43.503055 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
    (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27243,
    offset 0, flags [DF], proto TCP (6), length 60)
        10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect
    -> 0x48d9), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
    4294837885 ecr 0,nop,wscale 7], length 0
    10:12:44.505556 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
    (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27244,
    offset 0, flags [DF], proto TCP (6), length 60)
        10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect
    -> 0x44ee), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
    4294838888 ecr 0,nop,wscale 7], length 0
    
    This connection finally times out.
    
    I've only access to the TG3 hardware in this configuration thus have
    only tested this with TG3 driver.  There are a lot of other drivers
    that do not permit user changes to vlan acceleration features, and
    I don't know if they all suffere from a similar issue.
    
    The patch attempt to fix this another way.  It moves the vlan header
    stipping code out of the vlan module and always builds it into the
    kernel network core.  This way, even if vlan is not supported on
    a virtualizatoin host, the virtual machines running on top of such
    host will still work with VLANs enabled.
    
    CC: Patrick McHardy <kaber@trash.net>
    CC: Nithin Nayak Sujir <nsujir@broadcom.com>
    CC: Michael Chan <mchan@broadcom.com>
    CC: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Acked-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5794d8f0eb051c58c0b854e39dbff863243cc89e
Author: Jiri Benc <jbenc@redhat.com>
Date:   Fri Aug 8 16:44:32 2014 +0200

    rtnetlink: fix VF info size
    
    [ Upstream commit 945a36761fd7877660f630bbdeb4ff9ff80d1935 ]
    
    Commit 1d8faf48c74b8 ("net/core: Add VF link state control") added new
    attribute to IFLA_VF_INFO group in rtnl_fill_ifinfo but did not adjust size
    of the allocated memory in if_nlmsg_size/rtnl_vfinfo_size. As the result, we
    may trigger warnings in rtnl_getlink and similar functions when many VF
    links are enabled, as the information does not fit into the allocated skb.
    
    Fixes: 1d8faf48c74b8 ("net/core: Add VF link state control")
    Reported-by: Yulong Pei <ypei@redhat.com>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3298e331fa90fb04800cbc88ce25f7be30acd241
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 7 22:22:47 2014 +0200

    netlink: reset network header before passing to taps
    
    [ Upstream commit 4e48ed883c72e78c5a910f8831ffe90c9b18f0ec ]
    
    netlink doesn't set any network header offset thus when the skb is
    being passed to tap devices via dev_queue_xmit_nit(), it emits klog
    false positives due to it being unset like:
    
      ...
      [  124.990397] protocol 0000 is buggy, dev nlmon0
      [  124.990411] protocol 0000 is buggy, dev nlmon0
      ...
    
    So just reset the network header before passing to the device; for
    packet sockets that just means nothing will change - mac and net
    offset hold the same value just as before.
    
    Reported-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f8af8eeb8306a965973c3061630d6975cab5e76c
Author: David Jeffery <djeffery@redhat.com>
Date:   Tue Aug 5 11:19:42 2014 -0400

    nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
    
    commit 92a56555bd576c61b27a5cab9f38a33a1e9a1df5 upstream.
    
    If a SIGKILL is sent to a task waiting in __nfs_iocounter_wait,
    it will busy-wait or soft lockup in its while loop.
    nfs_wait_bit_killable won't sleep, and the loop won't exit on
    the error return.
    
    Stop the busy-wait by breaking out of the loop when
    nfs_wait_bit_killable returns an error.
    
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: Neil Brown <nfbrown@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 645ccc08110dd0f49c2d94e58f26d567921d5a5f
Author: Lars Ellenberg <lars.ellenberg@linbit.com>
Date:   Wed Jul 9 21:18:32 2014 +0200

    drbd: fix regression 'out of mem, failed to invoke fence-peer helper'
    
    commit bbc1c5e8ad6dfebf9d13b8a4ccdf66c92913eac9 upstream.
    
    Since linux kernel 3.13, kthread_run() internally uses
    wait_for_completion_killable().  We sometimes may use kthread_run()
    while we still have a signal pending, which we used to kick our threads
    out of potentially blocking network functions, causing kthread_run() to
    mistake that as a new fatal signal and fail.
    
    Fix: flush_signals() before kthread_run().
    
    Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e30949769ea506e24072817eddaabeb87c653571
Author: Andrew Hunter <ahh@google.com>
Date:   Thu Sep 4 14:17:16 2014 -0700

    jiffies: Fix timeval conversion to jiffies
    
    commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream.
    
    timeval_to_jiffies tried to round a timeval up to an integral number
    of jiffies, but the logic for doing so was incorrect: intervals
    corresponding to exactly N jiffies would become N+1. This manifested
    itself particularly repeatedly stopping/starting an itimer:
    
    setitimer(ITIMER_PROF, &val, NULL);
    setitimer(ITIMER_PROF, NULL, &val);
    
    would add a full tick to val, _even if it was exactly representable in
    terms of jiffies_ (say, the result of a previous rounding.)  Doing
    this repeatedly would cause unbounded growth in val.  So fix the math.
    
    Here's what was wrong with the conversion: we essentially computed
    (eliding seconds)
    
    jiffies = usec  * (NSEC_PER_USEC/TICK_NSEC)
    
    by using scaling arithmetic, which took the best approximation of
    NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
    x/(2^USEC_JIFFIE_SC), and computed:
    
    jiffies = (usec * x) >> USEC_JIFFIE_SC
    
    and rounded this calculation up in the intermediate form (since we
    can't necessarily exactly represent TICK_NSEC in usec.) But the
    scaling arithmetic is a (very slight) *over*approximation of the true
    value; that is, instead of dividing by (1 usec/ 1 jiffie), we
    effectively divided by (1 usec/1 jiffie)-epsilon (rounding
    down). This would normally be fine, but we want to round timeouts up,
    and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
    would be fine if our division was exact, but dividing this by the
    slightly smaller factor was equivalent to adding just _over_ 1 to the
    final result (instead of just _under_ 1, as desired.)
    
    In particular, with HZ=1000, we consistently computed that 10000 usec
    was 11 jiffies; the same was true for any exact multiple of
    TICK_NSEC.
    
    We could possibly still round in the intermediate form, adding
    something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
    convert usec->nsec, round in nanoseconds, and then convert using
    time*spec*_to_jiffies.  This adds one constant multiplication, and is
    not observably slower in microbenchmarks on recent x86 hardware.
    
    Tested: the following program:
    
    int main() {
      struct itimerval zero = {{0, 0}, {0, 0}};
      /* Initially set to 10 ms. */
      struct itimerval initial = zero;
      initial.it_interval.tv_usec = 10000;
      setitimer(ITIMER_PROF, &initial, NULL);
      /* Save and restore several times. */
      for (size_t i = 0; i < 10; ++i) {
        struct itimerval prev;
        setitimer(ITIMER_PROF, &zero, &prev);
        /* on old kernels, this goes up by TICK_USEC every iteration */
        printf("previous value: %ld %ld %ld %ld\n",
               prev.it_interval.tv_sec, prev.it_interval.tv_usec,
               prev.it_value.tv_sec, prev.it_value.tv_usec);
        setitimer(ITIMER_PROF, &prev, NULL);
      }
        return 0;
    }
    
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Paul Turner <pjt@google.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Reviewed-by: Paul Turner <pjt@google.com>
    Reported-by: Aaron Jacobs <jacobsa@google.com>
    Signed-off-by: Andrew Hunter <ahh@google.com>
    [jstultz: Tweaked to apply to 3.17-rc]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1d5b4f75c30a69df306e53869d44206555147c62
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Sat Sep 20 16:16:35 2014 -0300

    media: vb2: fix VBI/poll regression
    
    commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream.
    
    The recent conversion of saa7134 to vb2 unconvered a poll() bug that
    broke the teletext applications alevt and mtt. These applications
    expect that calling poll() without having called VIDIOC_STREAMON will
    cause poll() to return POLLERR. That did not happen in vb2.
    
    This patch fixes that behavior. It also fixes what should happen when
    poll() is called when STREAMON is called but no buffers have been
    queued. In that case poll() will also return POLLERR, but only for
    capture queues since output queues will always return POLLOUT
    anyway in that situation.
    
    This brings the vb2 behavior in line with the old videobuf behavior.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 91d5b067629d4880f8ce6386c6af6bd64579e124
Author: Mel Gorman <mgorman@suse.de>
Date:   Thu Oct 2 19:47:42 2014 +0100

    mm: numa: Do not mark PTEs pte_numa when splitting huge pages
    
    commit abc40bd2eeb77eb7c2effcaf63154aad929a1d5f upstream.
    
    This patch reverts 1ba6e0b50b ("mm: numa: split_huge_page: transfer the
    NUMA type from the pmd to the pte"). If a huge page is being split due
    a protection change and the tail will be in a PROT_NONE vma then NUMA
    hinting PTEs are temporarily created in the protected VMA.
    
     VM_RW|VM_PROTNONE
    |-----------------|
          ^
          split here
    
    In the specific case above, it should get fixed up by change_pte_range()
    but there is a window of opportunity for weirdness to happen. Similarly,
    if a huge page is shrunk and split during a protection update but before
    pmd_numa is cleared then a pte_numa can be left behind.
    
    Instead of adding complexity trying to deal with the case, this patch
    will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults
    will not be triggered which is marginal in comparison to the complexity
    in dealing with the corner cases during THP split.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 46710d8df2c62648e35fff8ceb160ad5122d7893
Author: Waiman Long <Waiman.Long@hp.com>
Date:   Wed Aug 6 16:05:36 2014 -0700

    mm, thp: move invariant bug check out of loop in __split_huge_page_map
    
    commit f8303c2582b889351e261ff18c4d8eb197a77db2 upstream.
    
    In __split_huge_page_map(), the check for page_mapcount(page) is
    invariant within the for loop.  Because of the fact that the macro is
    implemented using atomic_read(), the redundant check cannot be optimized
    away by the compiler leading to unnecessary read to the page structure.
    
    This patch moves the invariant bug check out of the loop so that it will
    be done only once.  On a 3.16-rc1 based kernel, the execution time of a
    microbenchmark that broke up 1000 transparent huge pages using munmap()
    had an execution time of 38,245us and 38,548us with and without the
    patch respectively.  The performance gain is about 1%.
    
    Signed-off-by: Waiman Long <Waiman.Long@hp.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Scott J Norton <scott.norton@hp.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 27489f205b7c1439ef19bbb1f524f6bac83cf097
Author: Pavel Shilovsky <pshilovsky@samba.org>
Date:   Mon Aug 18 20:49:57 2014 +0400

    CIFS: Fix SMB2 readdir error handling
    
    commit 52755808d4525f4d5b86d112d36ffc7a46f3fb48 upstream.
    
    SMB2 servers indicates the end of a directory search with
    STATUS_NO_MORE_FILE error code that is not processed now.
    This causes generic/257 xfstest to fail. Fix this by triggering
    the end of search by this error code in SMB2_query_directory.
    
    Also when negotiating CIFS protocol we tell the server to close
    the search automatically at the end and there is no need to do
    it itself. In the case of SMB2 protocol, we need to close it
    explicitly - separate close directory checks for different
    protocols.
    
    Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3cd8dcbf83c285f4fcb563c7bc8ac939d1a90c11
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Oct 2 16:51:18 2014 -0400

    ring-buffer: Fix infinite spin in reading buffer
    
    commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream.
    
    Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page"
    fixed one bug but in the process caused another one. The reset is to
    update the header page, but that fix also changed the way the cached
    reads were updated. The cache reads are used to test if an iterator
    needs to be updated or not.
    
    A ring buffer iterator, when created, disables writes to the ring buffer
    but does not stop other readers or consuming reads from happening.
    Although all readers are synchronized via a lock, they are only
    synchronized when in the ring buffer functions. Those functions may
    be called by any number of readers. The iterator continues down when
    its not interrupted by a consuming reader. If a consuming read
    occurs, the iterator starts from the beginning of the buffer.
    
    The way the iterator sees that a consuming read has happened since
    its last read is by checking the reader "cache". The cache holds the
    last counts of the read and the reader page itself.
    
    Commit 651e22f2701b changed what was saved by the cache_read when
    the rb_iter_reset() occurred, making the iterator never match the cache.
    Then if the iterator calls rb_iter_reset(), it will go into an
    infinite loop by checking if the cache doesn't match, doing the reset
    and retrying, just to see that the cache still doesn't match! Which
    should never happen as the reset is suppose to set the cache to the
    current value and there's locks that keep a consuming reader from
    having access to the data.
    
    Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 60c381273d75c0e9447c04603ce7cc5bf203f11d
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Fri Oct 3 16:19:24 2014 -0700

    init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu
    
    commit 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f upstream.
    
    commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow
    architectures to skip futex_atomic_cmpxchg_inatomic() test") added the
    HAVE_FUTEX_CMPXCHG symbol right below FUTEX.  This placed it right in
    the middle of the options for the EXPERT menu.  However,
    HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops
    placing items in the EXPERT menu, and displays the remaining several
    EXPERT items (starting with EPOLL) directly in the General Setup menu.
    
    Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make
    HAVE_FUTEX_CMPXCHG itself depend on FUTEX.  With this change, the
    subsequent items display as part of the EXPERT menu again; the EMBEDDED
    menu now appears as the next top-level item in the General Setup menu,
    which makes General Setup much shorter and more usable.
    
    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7854c22e747f2400b14c19130c27e6b93b7d994d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Sep 25 10:13:12 2014 +0100

    drm/i915: Flush the PTEs after updating them before suspend
    
    commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream.
    
    As we use WC updates of the PTE, we are responsible for notifying the
    hardware when to flush its TLBs. Do so after we zap all the PTEs before
    suspend (and the BIOS tries to read our GTT).
    
    Fixes a regression from
    
    commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
    Author: Ben Widawsky <benjamin.widawsky@intel.com>
    Date:   Wed Oct 16 09:21:30 2013 -0700
    
        drm/i915: Disable GGTT PTEs on GEN6+ suspend
    
    that survived and continue to cause harm even after
    
    commit e568af1c626031925465a5caaab7cca1303d55c7
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Mar 26 20:08:20 2014 +0100
    
        drm/i915: Undo gtt scratch pte unmapping again
    
    v2: Trivial rebase.
    v3: Fixes requires pointer dances.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
    Tested-by: ming.yao@intel.com
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Cc: Todd Previte <tprevite@gmail.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 35d986264a11808558b48ad293e898a6d651f6d0
Author: NeilBrown <neilb@suse.de>
Date:   Thu Oct 2 13:45:00 2014 +1000

    md/raid5: disable 'DISCARD' by default due to safety concerns.
    
    commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream.
    
    It has come to my attention (thanks Martin) that 'discard_zeroes_data'
    is only a hint.  Some devices in some cases don't do what it
    says on the label.
    
    The use of DISCARD in RAID5 depends on reads from discarded regions
    being predictably zero.  If a write to a previously discarded region
    performs a read-modify-write cycle it assumes that the parity block
    was consistent with the data blocks.  If all were zero, this would
    be the case.  If some are and some aren't this would not be the case.
    This could lead to data corruption after a device failure when
    data needs to be reconstructed from the parity.
    
    As we cannot trust 'discard_zeroes_data', ignore it by default
    and so disallow DISCARD on all raid4/5/6 arrays.
    
    As many devices are trustworthy, and as there are benefits to using
    DISCARD, add a module parameter to over-ride this caution and cause
    DISCARD to work if discard_zeroes_data is set.
    
    If a site want to enable DISCARD on some arrays but not on others they
    should select DISCARD support at the filesystem level, and set the
    raid456 module parameter.
        raid456.devices_handle_discard_safely=Y
    
    As this is a data-safety issue, I believe this patch is suitable for
    -stable.
    DISCARD support for RAID456 was added in 3.7
    
    Cc: Shaohua Li <shli@kernel.org>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Heinz Mauelshagen <heinzm@redhat.com>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Acked-by: Mike Snitzer <snitzer@redhat.com>
    Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 942c63742e91e10f3af9a1bdc932a52d63b6450e
Author: Mel Gorman <mgorman@suse.de>
Date:   Thu Oct 2 19:47:41 2014 +0100

    mm: migrate: Close race between migration completion and mprotect
    
    commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream.
    
    A migration entry is marked as write if pte_write was true at the time the
    entry was created. The VMA protections are not double checked when migration
    entries are being removed as mprotect marks write-migration-entries as
    read. It means that potentially we take a spurious fault to mark PTEs write
    again but it's straight-forward. However, there is a race between write
    migrations being marked read and migrations finishing. This potentially
    allows a PTE to be write that should have been read. Close this race by
    double checking the VMA permissions using maybe_mkwrite when migration
    completes.
    
    [torvalds@linux-foundation.org: use maybe_mkwrite]
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 07b5661fe33df525931853f6869f7f5fd68d291e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Oct 2 16:17:02 2014 -0700

    perf: fix perf bug in fork()
    
    commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream.
    
    Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
    calling perf_event_free_task() when failing sched_fork() we will not yet
    have done the memset() on ->perf_event_ctxp[] and will therefore try and
    'free' the inherited contexts, which are still in use by the parent
    process.  This is bad..
    
    Suggested-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    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 8ec4e9789b8b4c05ee979daad2a27088e29fac5d
Author: Jan Kara <jack@suse.cz>
Date:   Thu Sep 4 14:06:55 2014 +0200

    udf: Avoid infinite loop when processing indirect ICBs
    
    commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 upstream.
    
    We did not implement any bound on number of indirect ICBs we follow when
    loading inode. Thus corrupted medium could cause kernel to go into an
    infinite loop, possibly causing a stack overflow.
    
    Fix the possible stack overflow by removing recursion from
    __udf_read_inode() and limit number of indirect ICBs we follow to avoid
    infinite loops.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5685ae089da74713b5d2f487fd20e151e347f440
Author: Rajendra Nayak <rnayak@ti.com>
Date:   Wed Aug 27 19:38:22 2014 -0600

    ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
    
    commit af438fec6cb99fc2e2faf8b16b865af26ce722e6 upstream.
    
    Use the corresponding compatibles to identify the devices.
    
    Signed-off-by: Rajendra Nayak <rnayak@ti.com>
    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
    Acked-by: Nishanth Menon <nm@ti.com>
    Tested-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit be26e62cec162ff53a104ef6dc66a74e368c16e4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jun 20 14:23:28 2014 +0200

    staging/lustre: disable virtual block device for 64K pages
    
    commit 0bf22be0da8ea74bc7ccc5b07d7855830be16eca upstream.
    
    The lustre virtual block device cannot handle 64K pages and fails at compile
    time. To avoid running into this error, let's disable the Kconfig option
    for this driver in cases it doesn't support.
    
    Reported-by: Dann Frazier <dann.frazier@canonical.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 88e350c62c63bb4ae5887bfbbad88e3354e7ce6f
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date:   Wed Sep 3 17:45:44 2014 +0800

    aio: block exit_aio() until all context requests are completed
    
    commit 6098b45b32e6baeacc04790773ced9340601d511 upstream.
    
    It seems that exit_aio() also needs to wait for all iocbs to complete (like
    io_destroy), but we missed the wait step in current implemention, so fix
    it in the same way as we did in io_destroy.
    
    Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3386c069c54344797c4d2da55ebef2f555a7a4a3
Author: Tero Kristo <t-kristo@ti.com>
Date:   Thu Aug 21 16:47:45 2014 +0300

    clk: prevent erronous parsing of children during rate change
    
    commit 067bb1741c27c8d3b74ac98c0b8fc12b31e67005 upstream.
    
    In some cases, clocks can switch their parent with clk_set_rate, for
    example clk_mux can do this in some cases. Current implementation of
    clk_change_rate uses un-safe list iteration on the clock children, which
    will cause wrong clocks to be parsed in case any of the clock children
    change their parents during the change rate operation. Fixed by using
    the safe list iterator instead.
    
    The problem was detected due to some divide by zero errors generated
    by clock init on dra7-evm board, see discussion under
    http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
    
    Fixes: 71472c0c06cf ("clk: add support for clock reparent on set_rate")
    Signed-off-by: Tero Kristo <t-kristo@ti.com>
    Reported-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0dd03a746211ee0b7a901e382fdf8c15acbde80c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Aug 5 11:09:59 2014 +0300

    partitions: aix.c: off by one bug
    
    commit d97a86c170b4e432f76db072a827fe30b4d6f659 upstream.
    
    The lvip[] array has "state->limit" elements so the condition here
    should be >= instead of >.
    
    Fixes: 6ceea22bbbc8 ('partitions: add aix lvm partition support files')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Philippe De Muyter <phdm@macqel.be>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a989feb087a51f54e00e36baace383cfffbf5fdb
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Jun 18 12:15:38 2014 +0300

    dmaengine: dw: don't perform DMA when dmaengine_submit is called
    
    commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream.
    
    Accordingly to discussion [1] and followed up documentation the DMA controller
    driver shouldn't start any DMA operations when dmaengine_submit() is called.
    
    This patch fixes the workflow in dw_dmac driver to follow the documentation.
    
    [1] http://www.spinics.net/lists/arm-kernel/msg125987.html
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e3c2bf19e5823dd742ad32ae9394143ae26effb1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Jun 18 12:15:36 2014 +0300

    dmaengine: dw: introduce dwc_dostart_first_queued() helper
    
    commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream.
    
    We have a duplicate code which starts first descriptor in the queue. Let's make
    this as a separate helper that can be used in future as well.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 77043778de5e2e9c906d9a4a901feabbeac44265
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Mon Apr 28 15:59:56 2014 +0300

    serial: 8250_dma: check the result of TX buffer mapping
    
    commit d4089a332883ad969700aac5dd4dd5f1c4fee825 upstream.
    
    Using dma_mapping_error() to make sure the mapping did not
    fail.
    
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c7aa3df027f72ce81e02a3775e789fb7c039aefa
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon May 26 13:40:53 2014 +0200

    PM / sleep: Use valid_state() for platform-dependent sleep states only
    
    commit 43e8317b0bba1d6eb85f38a4a233d82d7c20d732 upstream.
    
    Use the observation that, for platform-dependent sleep states
    (PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
    always supported or always unsupported and store that information
    in pm_states[] instead of calling valid_state() every time we
    need to check it.
    
    Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
    valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
    directly into enter_state().
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0a6592eecd584ef71049ae724cacb49af84af898
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon May 26 13:40:47 2014 +0200

    PM / sleep: Add state field to pm_states[] entries
    
    commit 27ddcc6596e50cb8f03d2e83248897667811d8f6 upstream.
    
    To allow sleep states corresponding to the "mem", "standby" and
    "freeze" lables to be different from the pm_states[] indexes of
    those strings, introduce struct pm_sleep_state, consisting of
    a string label and a state number, and turn pm_states[] into an
    array of objects of that type.
    
    This modification should not lead to any functional changes.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 995925f1ecd8c80bb265153119362c495648a91e
Author: NeilBrown <neilb@suse.de>
Date:   Thu Sep 18 11:09:04 2014 +1000

    md/raid1: fix_read_error should act on all non-faulty devices.
    
    commit b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd upstream.
    
    If a devices is being recovered it is not InSync and is not Faulty.
    
    If a read error is experienced on that device, fix_read_error()
    will be called, but it ignores non-InSync devices.  So it will
    neither fix the error nor fail the device.
    
    It is incorrect that fix_read_error() ignores non-InSync devices.
    It should only ignore Faulty devices.  So fix it.
    
    This became a bug when we allowed reading from a device that was being
    recovered.  It is suitable for any subsequent -stable kernel.
    
    Fixes: da8840a747c0dbf49506ec906757a6b87b9741e9
    Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
    Tested-by: Alexander Lyakas <alex.bolshoy@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e1a45c6066dc65d03dd5a56b75c6baab813d9c1b
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Fri Sep 12 06:02:02 2014 -0300

    media: adv7604: fix inverted condition
    
    commit 77639ff2b3404a913b8037d230a384798b854bae upstream.
    
    The log_status function should show HDMI information, but the test checking for
    an HDMI input was inverted. Fix this.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 43da6d0f493813fd4f235dc64f5bb4a4dce99138
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Aug 26 02:59:53 2014 -0300

    media: cx18: fix kernel oops with tda8290 tuner
    
    commit 6a03dc92cc2edfa2257502557b9f714893987383 upstream.
    
    This was caused by an uninitialized setup.config field.
    
    Based on a suggestion from Devin Heitmueller.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Thanks-to: Devin Heitmueller <dheitmueller@kernellabs.com>
    Reported-by: Scott Robinson <scott.robinson55@gmail.com>
    Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b37091dddc1740b3a516004b29dca18bca84b314
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 30 14:55:26 2014 +0200

    nl80211: clear skb cb before passing to netlink
    
    commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream.
    
    In testmode and vendor command reply/event SKBs we use the
    skb cb data to store nl80211 parameters between allocation
    and sending. This causes the code for CONFIG_NETLINK_MMAP
    to get confused, because it takes ownership of the skb cb
    data when the SKB is handed off to netlink, and it doesn't
    explicitly clear it.
    
    Clear the skb cb explicitly when we're done and before it
    gets passed to netlink to avoid this issue.
    
    Reported-by: Assaf Azulay <assaf.azulay@intel.com>
    Reported-by: David Spinadel <david.spinadel@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2db0c704fe90710368581c2dcf5d33105a9b9600
Author: Anton Altaparmakov <aia21@cam.ac.uk>
Date:   Mon Sep 22 01:53:03 2014 +0100

    Fix nasty 32-bit overflow bug in buffer i/o code.
    
    commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream.
    
    On 32-bit architectures, the legacy buffer_head functions are not always
    handling the sector number with the proper 64-bit types, and will thus
    fail on 4TB+ disks.
    
    Any code that uses __getblk() (and thus bread(), breadahead(),
    sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit
    block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop
    in __getblk_slow() with an infinite stream of errors logged to dmesg
    like this:
    
      __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
      b_state=0x00000020, b_size=512
      device sda1 blocksize: 512
    
    Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
    top 32-bits are missing (in this case the 0x1 at the top).
    
    This is because grow_dev_page() is broken and has a 32-bit overflow due
    to shifting the page index value (a pgoff_t - which is just 32 bits on
    32-bit architectures) left-shifted as the block number.  But the top
    bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit
    before the shift.
    
    This patch fixes this issue by type casting "index" to sector_t before
    doing the left shift.
    
    Note this is not a theoretical bug but has been seen in the field on a
    4TiB hard drive with logical sector size 512 bytes.
    
    This patch has been verified to fix the infinite loop problem on 3.17-rc5
    kernel using a 4TB disk image mounted using "-o loop".  Without this patch
    doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
    100% reproducibly whilst with the patch it works fine as expected.
    
    Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fa13e3ec566c51c84975730b34d9da3c1c412992
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 12 18:06:56 2014 -0400

    drm/nouveau/runpm: fix module unload
    
    commit 53beaa01e0fe8e4202f43485a03b32fcf5dfea74 upstream.
    
    Use the new vga_switcheroo_fini_domain_pm_ops function
    to unregister the pm ops.
    
    Based on a patch from:
    Pali Rohár <pali.rohar@gmail.com>
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=84431
    
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5509a38bd19bedccb64c1b3418460ad51f24edff
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 12 17:51:29 2014 -0400

    vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
    
    commit 766a53d059d1500c9755c8af017bd411bd8f1b20 upstream.
    
    Drivers should call this on unload to unregister pmops.
    
    Bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=84431
    
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
    Cc: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fcf9b1a79fc8974f89e5c0244c560fc3c815ae87
Author: Cong Wang <cwang@twopensource.com>
Date:   Tue Sep 2 15:27:20 2014 -0700

    perf: Fix a race condition in perf_remove_from_context()
    
    commit 3577af70a2ce4853d58e57d832e687d739281479 upstream.
    
    We saw a kernel soft lockup in perf_remove_from_context(),
    it looks like the `perf` process, when exiting, could not go
    out of the retry loop. Meanwhile, the target process was forking
    a child. So either the target process should execute the smp
    function call to deactive the event (if it was running) or it should
    do a context switch which deactives the event.
    
    It seems we optimize out a context switch in perf_event_context_sched_out(),
    and what's more important, we still test an obsolete task pointer when
    retrying, so no one actually would deactive that event in this situation.
    Fix it directly by reloading the task pointer in perf_remove_from_context().
    
    This should cure the above soft lockup.
    
    Signed-off-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8d9376b83508b95e38746932944ab42133053103
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri Sep 19 08:32:19 2014 -0400

    IB/qib: Correct reference counting in debugfs qp_stats
    
    commit 85cbb7c728bf39c45a9789b88c9471c0d7a58b0e upstream.
    
    This particular reference count is not needed with the rcu protection,
    and the current code leaks a reference count, causing a hang in
    qib_qp_destroy().
    
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6b492bab9c4edd84769ff057200b95c709e4b891
Author: Richard Larocque <rlarocque@google.com>
Date:   Tue Sep 9 18:31:05 2014 -0700

    alarmtimer: Lock k_itimer during timer callback
    
    commit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream.
    
    Locks the k_itimer's it_lock member when handling the alarm timer's
    expiry callback.
    
    The regular posix timers defined in posix-timers.c have this lock held
    during timout processing because their callbacks are routed through
    posix_timer_fn().  The alarm timers follow a different path, so they
    ought to grab the lock somewhere else.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Sharvil Nanavati <sharvil@google.com>
    Signed-off-by: Richard Larocque <rlarocque@google.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e1f7a680a82fdc7a43fcc6fc5433b1aa13a0f427
Author: Richard Larocque <rlarocque@google.com>
Date:   Tue Sep 9 18:31:04 2014 -0700

    alarmtimer: Do not signal SIGEV_NONE timers
    
    commit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream.
    
    Avoids sending a signal to alarm timers created with sigev_notify set to
    SIGEV_NONE by checking for that special case in the timeout callback.
    
    The regular posix timers avoid sending signals to SIGEV_NONE timers by
    not scheduling any callbacks for them in the first place.  Although it
    would be possible to do something similar for alarm timers, it's simpler
    to handle this as a special case in the timeout.
    
    Prior to this patch, the alarm timer would ignore the sigev_notify value
    and try to deliver signals to the process anyway.  Even worse, the
    sanity check for the value of sigev_signo is skipped when SIGEV_NONE was
    specified, so the signal number could be bogus.  If sigev_signo was an
    unitialized value (as it often would be if SIGEV_NONE is used), then
    it's hard to predict which signal will be sent.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Sharvil Nanavati <sharvil@google.com>
    Signed-off-by: Richard Larocque <rlarocque@google.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ddedde0079395e4d46bd74af5c82adac1a70d0a0
Author: Richard Larocque <rlarocque@google.com>
Date:   Tue Sep 9 18:31:03 2014 -0700

    alarmtimer: Return relative times in timer_gettime
    
    commit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream.
    
    Returns the time remaining for an alarm timer, rather than the time at
    which it is scheduled to expire.  If the timer has already expired or it
    is not currently scheduled, the it_value's members are set to zero.
    
    This new behavior matches that of the other posix-timers and the POSIX
    specifications.
    
    This is a change in user-visible behavior, and may break existing
    applications.  Hopefully, few users rely on the old incorrect behavior.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Sharvil Nanavati <sharvil@google.com>
    Signed-off-by: Richard Larocque <rlarocque@google.com>
    [jstultz: minor style tweak]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4a472616d226281c8e6b26d0457ebae8fe8135a4
Author: John David Anglin <dave.anglin@bell.net>
Date:   Mon Sep 22 20:54:50 2014 -0400

    parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds
    
    commit d26a7730b5874a5fa6779c62f4ad7c5065a94723 upstream.
    
    In spite of what the GCC manual says, the -mfast-indirect-calls has
    never been supported in the 64-bit parisc compiler. Indirect calls have
    always been done using function descriptors irrespective of the
    -mfast-indirect-calls option.
    
    Recently, it was noticed that a function descriptor was always requested
    when the -mfast-indirect-calls option was specified. This caused
    problems when the option was used in  application code and doesn't make
    any sense because the whole point of the option is to avoid using a
    function descriptor for indirect calls.
    
    Fixing this broke 64-bit kernel builds.
    
    I will fix GCC but for now we need the attached change. This results in
    the same kernel code as before.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 11dbe17a1d27cb81e06c52e631de8bc2b17c5e5c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Sep 13 21:55:46 2014 -0400

    don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
    
    commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream.
    
    return the value instead, and have path_init() do the assignment.  Broken by
    "vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
    which was Cc-stable with 2.6.38+ as destination.  This one should go where
    it went.
    
    To avoid dummy value returned in case when root is already set (it would do
    no harm, actually, since the only caller that doesn't ignore the return value
    is guaranteed to have nd->root *not* set, but it's more obvious that way),
    lift the check into callers.  And do the same to set_root(), to keep them
    in sync.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6b4238b59f17764ee24f7e1731ef9a037758394d
Author: Wanpeng Li <wanpeng.li@linux.intel.com>
Date:   Wed Sep 24 16:38:05 2014 +0800

    sched: Fix unreleased llc_shared_mask bit during CPU hotplug
    
    commit 03bd4e1f7265548832a76e7919a81f3137c44fd1 upstream.
    
    The following bug can be triggered by hot adding and removing a large number of
    xen domain0's vcpus repeatedly:
    
    	BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
    	PGD 5a9d5067 PUD 13067 PMD 0
    	Oops: 0000 [#3] SMP
    	[...]
    	Call Trace:
    	load_balance
    	? _raw_spin_unlock_irqrestore
    	idle_balance
    	__schedule
    	schedule
    	schedule_timeout
    	? lock_timer_base
    	schedule_timeout_uninterruptible
    	msleep
    	lock_device_hotplug_sysfs
    	online_store
    	dev_attr_store
    	sysfs_write_file
    	vfs_write
    	SyS_write
    	system_call_fastpath
    
    Last level cache shared mask is built during CPU up and the
    build_sched_domain() routine takes advantage of it to setup
    the sched domain CPU topology.
    
    However, llc_shared_mask is not released during CPU disable,
    which leads to an invalid sched domainCPU topology.
    
    This patch fix it by releasing the llc_shared_mask correctly
    during CPU disable.
    
    Yasuaki also reported that this can happen on real hardware:
    
      https://lkml.org/lkml/2014/7/22/1018
    
    His case is here:
    
    	==
    	Here is an example on my system.
    	My system has 4 sockets and each socket has 15 cores and HT is
    	enabled. In this case, each core of sockes is numbered as
    	follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-44, 90-104
    	Socket#3 | 45-59, 105-119
    
    	Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.
    
    	It means that last level cache of Socket#2 is shared with
    	CPU#30-44 and 90-104.
    
    	When hot-removing socket#2 and #3, each core of sockets is
    	numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    
    	But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
    	remains having 0x3fff80000001fffc0000000.
    
    	After that, when hot-adding socket#2 and #3, each core of
    	sockets is numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-59
    	Socket#3 | 90-119
    
    	Then llc_shared_mask of CPU#30 becomes
    	0x3fff8000fffffffc0000000. It means that last level cache of
    	Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
    	the wrong value.
    
    Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
    Tested-by: Linn Crosetto <linn@hp.com>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Steven Rostedt <srostedt@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 26afc4e5f800cb490be0135bffd17313110c5a37
Author: David Rientjes <rientjes@google.com>
Date:   Thu Sep 25 16:05:20 2014 -0700

    mm, slab: initialize object alignment on cache creation
    
    commit d4a5fca592b9ab52b90bb261a90af3c8f53be011 upstream.
    
    Since commit 4590685546a3 ("mm/sl[aou]b: Common alignment code"), the
    "ralign" automatic variable in __kmem_cache_create() may be used as
    uninitialized.
    
    The proper alignment defaults to BYTES_PER_WORD and can be overridden by
    SLAB_RED_ZONE or the alignment specified by the caller.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=85031
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Reported-by: Andrei Elovikov <a.elovikov@gmail.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.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 df59eb8ea0f532ba8d503fbcc824df7df478bf27
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Thu Sep 25 16:05:16 2014 -0700

    ocfs2/dlm: do not get resource spinlock if lockres is new
    
    commit 5760a97c7143c208fa3a8f8cad0ed7dd672ebd28 upstream.
    
    There is a deadlock case which reported by Guozhonghua:
      https://oss.oracle.com/pipermail/ocfs2-devel/2014-September/010079.html
    
    This case is caused by &res->spinlock and &dlm->master_lock
    misordering in different threads.
    
    It was introduced by commit 8d400b81cc83 ("ocfs2/dlm: Clean up refmap
    helpers").  Since lockres is new, it doesn't not require the
    &res->spinlock.  So remove it.
    
    Fixes: 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers")
    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Reviewed-by: joyce.xue <xuejiufei@huawei.com>
    Reported-by: Guozhonghua <guozhonghua@h3c.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.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 207a97e3e2cb90e887b507e0798254cdf3589a83
Author: Andreas Rohner <andreas.rohner@gmx.net>
Date:   Thu Sep 25 16:05:14 2014 -0700

    nilfs2: fix data loss with mmap()
    
    commit 56d7acc792c0d98f38f22058671ee715ff197023 upstream.
    
    This bug leads to reproducible silent data loss, despite the use of
    msync(), sync() and a clean unmount of the file system.  It is easily
    reproducible with the following script:
    
      ----------------[BEGIN SCRIPT]--------------------
      mkfs.nilfs2 -f /dev/sdb
      mount /dev/sdb /mnt
    
      dd if=/dev/zero bs=1M count=30 of=/mnt/testfile
    
      umount /mnt
      mount /dev/sdb /mnt
      CHECKSUM_BEFORE="$(md5sum /mnt/testfile)"
    
      /root/mmaptest/mmaptest /mnt/testfile 30 10 5
    
      sync
      CHECKSUM_AFTER="$(md5sum /mnt/testfile)"
      umount /mnt
      mount /dev/sdb /mnt
      CHECKSUM_AFTER_REMOUNT="$(md5sum /mnt/testfile)"
      umount /mnt
    
      echo "BEFORE MMAP:\t$CHECKSUM_BEFORE"
      echo "AFTER MMAP:\t$CHECKSUM_AFTER"
      echo "AFTER REMOUNT:\t$CHECKSUM_AFTER_REMOUNT"
      ----------------[END SCRIPT]--------------------
    
    The mmaptest tool looks something like this (very simplified, with
    error checking removed):
    
      ----------------[BEGIN mmaptest]--------------------
      data = mmap(NULL, file_size - file_offset, PROT_READ | PROT_WRITE,
                  MAP_SHARED, fd, file_offset);
    
      for (i = 0; i < write_count; ++i) {
            memcpy(data + i * 4096, buf, sizeof(buf));
            msync(data, file_size - file_offset, MS_SYNC))
      }
      ----------------[END mmaptest]--------------------
    
    The output of the script looks something like this:
    
      BEFORE MMAP:    281ed1d5ae50e8419f9b978aab16de83  /mnt/testfile
      AFTER MMAP:     6604a1c31f10780331a6850371b3a313  /mnt/testfile
      AFTER REMOUNT:  281ed1d5ae50e8419f9b978aab16de83  /mnt/testfile
    
    So it is clear, that the changes done using mmap() do not survive a
    remount.  This can be reproduced a 100% of the time.  The problem was
    introduced in commit 136e8770cd5d ("nilfs2: fix issue of
    nilfs_set_page_dirty() for page at EOF boundary").
    
    If the page was read with mpage_readpage() or mpage_readpages() for
    example, then it has no buffers attached to it.  In that case
    page_has_buffers(page) in nilfs_set_page_dirty() will be false.
    Therefore nilfs_set_file_dirty() is never called and the pages are never
    collected and never written to disk.
    
    This patch fixes the problem by also calling nilfs_set_file_dirty() if the
    page has no buffers attached to it.
    
    [akpm@linux-foundation.org: s/PAGE_SHIFT/PAGE_CACHE_SHIFT/]
    Signed-off-by: Andreas Rohner <andreas.rohner@gmx.net>
    Tested-by: Andreas Rohner <andreas.rohner@gmx.net>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 90aec2f784ca7492e9c3f16daac36fa38bb2e3f2
Author: Andrey Vagin <avagin@openvz.org>
Date:   Tue Sep 9 14:51:06 2014 -0700

    fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
    
    commit 7e8824816bda16bb11ff5ff1e1212d642e57b0b3 upstream.
    
    Currently we handle only ENOSPC.  In case of other errors the file_handle
    variable isn't filled properly and we will show a part of stack.
    
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    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 ea8544111ab0a86cd3264b3de190b97d06b4858d
Author: Andrey Vagin <avagin@openvz.org>
Date:   Tue Sep 9 14:51:04 2014 -0700

    fsnotify/fdinfo: use named constants instead of hardcoded values
    
    commit 1fc98d11cac6dd66342e5580cb2687e5b1e9a613 upstream.
    
    MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
    bytes, so exportfs_encode_inode_fh can return an error.
    
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    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 48133a704d319fbc05ae10c2622ba6c72fd6a746
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue Sep 9 14:51:01 2014 -0700

    kcmp: fix standard comparison bug
    
    commit acbbe6fbb240a927ee1f5994f04d31267d422215 upstream.
    
    The C operator <= defines a perfectly fine total ordering on the set of
    values representable in a long.  However, unlike its namesake in the
    integers, it is not translation invariant, meaning that we do not have
    "b <= c" iff "a+b <= a+c" for all a,b,c.
    
    This means that it is always wrong to try to boil down the relationship
    between two longs to a question about the sign of their difference,
    because the resulting relation [a LEQ b iff a-b <= 0] is neither
    anti-symmetric or transitive.  The former is due to -LONG_MIN==LONG_MIN
    (take any two a,b with a-b = LONG_MIN; then a LEQ b and b LEQ a, but a !=
    b).  The latter can either be seen observing that x LEQ x+1 for all x,
    implying x LEQ x+1 LEQ x+2 ...  LEQ x-1 LEQ x; or more directly with the
    simple example a=LONG_MIN, b=0, c=1, for which a-b < 0, b-c < 0, but a-c >
    0.
    
    Note that it makes absolutely no difference that a transmogrying bijection
    has been applied before the comparison is done.  In fact, had the
    obfuscation not been done, one could probably not observe the bug
    (assuming all values being compared always lie in one half of the address
    space, the mathematical value of a-b is always representable in a long).
    As it stands, one can easily obtain three file descriptors exhibiting the
    non-transitivity of kcmp().
    
    Side note 1: I can't see that ensuring the MSB of the multiplier is
    set serves any purpose other than obfuscating the obfuscating code.
    
    Side note 2:
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <assert.h>
    #include <sys/syscall.h>
    
    enum kcmp_type {
            KCMP_FILE,
            KCMP_VM,
            KCMP_FILES,
            KCMP_FS,
            KCMP_SIGHAND,
            KCMP_IO,
            KCMP_SYSVSEM,
            KCMP_TYPES,
    };
    pid_t pid;
    
    int kcmp(pid_t pid1, pid_t pid2, int type,
    	 unsigned long idx1, unsigned long idx2)
    {
    	return syscall(SYS_kcmp, pid1, pid2, type, idx1, idx2);
    }
    int cmp_fd(int fd1, int fd2)
    {
    	int c = kcmp(pid, pid, KCMP_FILE, fd1, fd2);
    	if (c < 0) {
    		perror("kcmp");
    		exit(1);
    	}
    	assert(0 <= c && c < 3);
    	return c;
    }
    int cmp_fdp(const void *a, const void *b)
    {
    	static const int normalize[] = {0, -1, 1};
    	return normalize[cmp_fd(*(int*)a, *(int*)b)];
    }
    #define MAX 100 /* This is plenty; I've seen it trigger for MAX==3 */
    int main(int argc, char *argv[])
    {
    	int r, s, count = 0;
    	int REL[3] = {0,0,0};
    	int fd[MAX];
    	pid = getpid();
    	while (count < MAX) {
    		r = open("/dev/null", O_RDONLY);
    		if (r < 0)
    			break;
    		fd[count++] = r;
    	}
    	printf("opened %d file descriptors\n", count);
    	for (r = 0; r < count; ++r) {
    		for (s = r+1; s < count; ++s) {
    			REL[cmp_fd(fd[r], fd[s])]++;
    		}
    	}
    	printf("== %d\t< %d\t> %d\n", REL[0], REL[1], REL[2]);
    	qsort(fd, count, sizeof(fd[0]), cmp_fdp);
    	memset(REL, 0, sizeof(REL));
    
    	for (r = 0; r < count; ++r) {
    		for (s = r+1; s < count; ++s) {
    			REL[cmp_fd(fd[r], fd[s])]++;
    		}
    	}
    	printf("== %d\t< %d\t> %d\n", REL[0], REL[1], REL[2]);
    	return (REL[0] + REL[2] != 0);
    }
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
    "Eric W. Biederman" <ebiederm@xmission.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 a07e826fcff97250c7c64ec1cd48aa5e88c46c11
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Tue Sep 9 14:50:51 2014 -0700

    eventpoll: fix uninitialized variable in epoll_ctl
    
    commit c680e41b3a2e944185c74bf60531e3d316d3ecc4 upstream.
    
    When calling epoll_ctl with operation EPOLL_CTL_DEL, structure epds is
    not initialized but ep_take_care_of_epollwakeup reads its event field.
    When this unintialized field has EPOLLWAKEUP bit set, a capability check
    is done for CAP_BLOCK_SUSPEND in ep_take_care_of_epollwakeup.  This
    produces unexpected messages in the audit log, such as (on a system
    running SELinux):
    
        type=AVC msg=audit(1408212798.866:410): avc:  denied
        { block_suspend } for  pid=7754 comm="dbus-daemon" capability=36
        scontext=unconfined_u:unconfined_r:unconfined_t
        tcontext=unconfined_u:unconfined_r:unconfined_t
        tclass=capability2 permissive=1
    
        type=SYSCALL msg=audit(1408212798.866:410): arch=c000003e syscall=233
        success=yes exit=0 a0=3 a1=2 a2=9 a3=7fffd4d66ec0 items=0 ppid=1
        pid=7754 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
        fsgid=0 tty=(none) ses=3 comm="dbus-daemon"
        exe="/usr/bin/dbus-daemon"
        subj=unconfined_u:unconfined_r:unconfined_t key=(null)
    
    ("arch=c000003e syscall=233 a1=2" means "epoll_ctl(op=EPOLL_CTL_DEL)")
    
    Remove use of epds in epoll_ctl when op == EPOLL_CTL_DEL.
    
    Fixes: 4d7e30d98939 ("epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready")
    Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Arve Hjønnevåg <arve@android.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 8cf91d68e8cbb9d79aafecd129464c18e5b6bbef
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 25 12:08:09 2014 +0200

    Revert "mac80211: disable uAPSD if all ACs are under ACM"
    
    commit bb512ad0732232f1d2693bb68f31a76bed8f22ae upstream.
    
    This reverts commit 24aa11ab8ae03292d38ec0dbd9bc2ac49fe8a6dd.
    
    That commit was wrong since it uses data that hasn't even been set
    up yet, but might be a hold-over from a previous connection.
    
    Additionally, it seems like a driver-specific workaround that
    shouldn't have been in mac80211 to start with.
    
    Fixes: 24aa11ab8ae0 ("mac80211: disable uAPSD if all ACs are under ACM")
    Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3a6e005e366f8b2e0f52e31e0b0a10ddbcc28d11
Author: Felipe Balbi <balbi@ti.com>
Date:   Wed Sep 3 16:13:37 2014 -0500

    usb: dwc3: core: fix ordering for PHY suspend
    
    commit dc99f16f076559235c92d3eb66d03d1310faea08 upstream.
    
    We can't suspend the PHYs before dwc3_core_exit_mode()
    has been called, that's because the host and/or device
    sides might still need to communicate with the far end
    link partner.
    
    Fixes: 8ba007a (usb: dwc3: core: enable the USB2 and USB3 phy in probe)
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ae0262d6fd9541429f2e2ec4949fe2c28443eb1e
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Sep 2 14:57:20 2014 -0500

    usb: dwc3: core: fix order of PM runtime calls
    
    commit fed33afce0eda44a46ae24d93aec1b5198c0bac4 upstream.
    
    Currently, we disable pm_runtime before all register
    accesses are done, this is dangerous and might lead
    to abort exceptions due to the driver trying to access
    a register which is clocked by a clock which was long
    gated.
    
    Fix that by moving pm_runtime_put_sync() and pm_runtime_disable()
    as the last thing we do before returning from our ->remove()
    method.
    
    Fixes: 72246da (usb: Introduce DesignWare USB3 DRD Driver)
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 00c18250ddb93de06e5eae5ba67c218b620eafa9
Author: Jens Axboe <axboe@fb.com>
Date:   Tue Sep 16 13:38:51 2014 -0600

    genhd: fix leftover might_sleep() in blk_free_devt()
    
    commit 46f341ffcfb5d8530f7d1e60f3be06cce6661b62 upstream.
    
    Commit 2da78092 changed the locking from a mutex to a spinlock,
    so we now longer sleep in this context. But there was a leftover
    might_sleep() in there, which now triggers since we do the final
    free from an RCU callback. Get rid of it.
    
    Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6130e3972af3bfe67c14e957b145abd5cceb3f6
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Aug 29 16:25:50 2014 -0400

    lockd: fix rpcbind crash on lockd startup failure
    
    commit 7c17705e77b12b20fb8afb7c1b15dcdb126c0c12 upstream.
    
    Nikita Yuschenko reported that booting a kernel with init=/bin/sh and
    then nfs mounting without portmap or rpcbind running using a busybox
    mount resulted in:
    
      # mount -t nfs 10.30.130.21:/opt /mnt
      svc: failed to register lockdv1 RPC service (errno 111).
      lockd_up: makesock failed, error=-111
      Unable to handle kernel paging request for data at address 0x00000030
      Faulting instruction address: 0xc055e65c
      Oops: Kernel access of bad area, sig: 11 [#1]
      MPC85xx CDS
      Modules linked in:
      CPU: 0 PID: 1338 Comm: mount Not tainted 3.10.44.cge #117
      task: cf29cea0 ti: cf35c000 task.ti: cf35c000
      NIP: c055e65c LR: c0566490 CTR: c055e648
      REGS: cf35dad0 TRAP: 0300   Not tainted  (3.10.44.cge)
      MSR: 00029000 <CE,EE,ME>  CR: 22442488  XER: 20000000
      DEAR: 00000030, ESR: 00000000
    
      GPR00: c05606f4 cf35db80 cf29cea0 cf0ded80 cf0dedb8 00000001 1dec3086
      00000000
      GPR08: 00000000 c07b1640 00000007 1dec3086 22442482 100b9758 00000000
      10090ae8
      GPR16: 00000000 000186a5 00000000 00000000 100c3018 bfa46edc 100b0000
      bfa46ef0
      GPR24: cf386ae0 c07834f0 00000000 c0565f88 00000001 cf0dedb8 00000000
      cf0ded80
      NIP [c055e65c] call_start+0x14/0x34
      LR [c0566490] __rpc_execute+0x70/0x250
      Call Trace:
      [cf35db80] [00000080] 0x80 (unreliable)
      [cf35dbb0] [c05606f4] rpc_run_task+0x9c/0xc4
      [cf35dbc0] [c0560840] rpc_call_sync+0x50/0xb8
      [cf35dbf0] [c056ee90] rpcb_register_call+0x54/0x84
      [cf35dc10] [c056f24c] rpcb_register+0xf8/0x10c
      [cf35dc70] [c0569e18] svc_unregister.isra.23+0x100/0x108
      [cf35dc90] [c0569e38] svc_rpcb_cleanup+0x18/0x30
      [cf35dca0] [c0198c5c] lockd_up+0x1dc/0x2e0
      [cf35dcd0] [c0195348] nlmclnt_init+0x2c/0xc8
      [cf35dcf0] [c015bb5c] nfs_start_lockd+0x98/0xec
      [cf35dd20] [c015ce6c] nfs_create_server+0x1e8/0x3f4
      [cf35dd90] [c0171590] nfs3_create_server+0x10/0x44
      [cf35dda0] [c016528c] nfs_try_mount+0x158/0x1e4
      [cf35de20] [c01670d0] nfs_fs_mount+0x434/0x8c8
      [cf35de70] [c00cd3bc] mount_fs+0x20/0xbc
      [cf35de90] [c00e4f88] vfs_kern_mount+0x50/0x104
      [cf35dec0] [c00e6e0c] do_mount+0x1d0/0x8e0
      [cf35df10] [c00e75ac] SyS_mount+0x90/0xd0
      [cf35df40] [c000ccf4] ret_from_syscall+0x0/0x3c
    
    The addition of svc_shutdown_net() resulted in two calls to
    svc_rpcb_cleanup(); the second is no longer necessary and crashes when
    it calls rpcb_register_call with clnt=NULL.
    
    Reported-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
    Fixes: 679b033df484 "lockd: ensure we tear down any live sockets when socket creation fails during lockd_up"
    Acked-by: Jeff Layton <jlayton@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7cb328c551175579b17a23ca4eeca73703b827bc
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Aug 24 17:49:43 2014 -0500

    rtlwifi: rtl8192cu: Add new ID
    
    commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream.
    
    The Sitecom WLA-2102 adapter uses this driver.
    
    Reported-by: Nico Baggus <nico-linux@noci.xs4all.nl>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Nico Baggus <nico-linux@noci.xs4all.nl>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 91a95b41f3abe8071e62193668f8c3e7dbd5e94f
Author: Eliad Peller <eliad@wizery.com>
Date:   Wed Jun 11 10:23:35 2014 +0300

    regulatory: add NUL to alpha2
    
    commit a5fe8e7695dc3f547e955ad2b662e3e72969e506 upstream.
    
    alpha2 is defined as 2-chars array, but is used in multiple
    places as string (e.g. with nla_put_string calls), which
    might leak kernel data.
    
    Solve it by simply adding an extra char for the NULL
    terminator, making such operations safe.
    
    Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e989b52a9136201d70b4b59b0b67885559d137d2
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Aug 15 16:06:10 2014 -0400

    percpu: perform tlb flush after pcpu_map_pages() failure
    
    commit 849f5169097e1ba35b90ac9df76b5bb6f9c0aabd upstream.
    
    If pcpu_map_pages() fails midway, it unmaps the already mapped pages.
    Currently, it doesn't flush tlb after the partial unmapping.  This may
    be okay in most cases as the established mapping hasn't been used at
    that point but it can go wrong and when it goes wrong it'd be
    extremely difficult to track down.
    
    Flush tlb after the partial unmapping.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 759ca68db061545dc0ebb687efdb90544cd2df68
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Aug 15 16:06:06 2014 -0400

    percpu: fix pcpu_alloc_pages() failure path
    
    commit f0d279654dea22b7a6ad34b9334aee80cda62cde upstream.
    
    When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to
    free what has already been allocated.  The invocation is across the
    whole requested range and pcpu_free_pages() will try to free all
    non-NULL pages; unfortunately, this is incorrect as
    pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't
    clear the pages array and thus the array may have entries from the
    previous invocations making the partial failure path free incorrect
    pages.
    
    Fix it by open-coding the partial freeing of the already allocated
    pages.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d1544eb455447cba71e7e90275642a85aebb1284
Author: Honggang Li <enjoymindful@gmail.com>
Date:   Tue Aug 12 21:36:15 2014 +0800

    percpu: free percpu allocation info for uniprocessor system
    
    commit 3189eddbcafcc4d827f7f19facbeddec4424eba8 upstream.
    
    Currently, only SMP system free the percpu allocation info.
    Uniprocessor system should free it too. For example, one x86 UML
    virtual machine with 256MB memory, UML kernel wastes one page memory.
    
    Signed-off-by: Honggang Li <enjoymindful@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 40be39a74449a11f103f0324eee3a510ecd7f94e
Author: James Ralston <james.d.ralston@intel.com>
Date:   Wed Aug 27 14:31:58 2014 -0700

    ata_piix: Add Device IDs for Intel 9 Series PCH
    
    commit 6cad1376954e591c3c41500c4e586e183e7ffe6d upstream.
    
    This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH.
    
    Signed-off-by: James Ralston <james.d.ralston@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 477e8e407b7de831dc447aa9e6e08d53009b0728
Author: Robert Coulson <rob.coulson@gmail.com>
Date:   Thu Aug 28 10:45:43 2014 -0700

    hwmon: (ds1621) Update zbits after conversion rate change
    
    commit 39c627a084475e8a690a4a9e7601410ca173ddd2 upstream.
    
    After the conversion rate is changed, the zbits are not updated,
    but should be, since they are used later in the set_temp function.
    
    Fixes: a50d9a4d9ad3 ("hwmon: (ds1621) Fix temperature rounding operations")
    Reported-by: Murat Ilsever <murat.ilsever@gmail.com>
    Signed-off-by: Robert Coulson <rob.coulson@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5fb5178e0d15cedc2c6fb48a5a614f3ed2fc9dc6
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Sep 11 10:10:26 2014 -0700

    Input: i8042 - add nomux quirk for Avatar AVIU-145A6
    
    commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream.
    
    The sys_vendor / product_name are somewhat generic unfortunately, so this
    may lead to some false positives. But nomux usually does no harm, where as
    not having it clearly is causing problems on the Avatar AVIU-145A6.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=77391
    
    Reported-by: Hugo P <saurosii@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d35a15b1f5a50ae84601f88ed381e5a0796149ac
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Sep 10 13:53:37 2014 -0700

    Input: i8042 - add Fujitsu U574 to no_timeout dmi table
    
    commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=69731
    
    Reported-by: Jason Robinson <mail@jasonrobinson.me>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6ed73cef360af391ce3c2e675b9cc407d35c6b1a
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Sep 10 13:50:37 2014 -0700

    Input: atkbd - do not try 'deactivate' keyboard on any LG laptops
    
    commit c01206796139e2b1feb7539bc72174fef1c6dc6e upstream.
    
    We are getting more and more reports about LG laptops not having
    functioning keyboard if we try to deactivate keyboard during probe.
    Given that having keyboard deactivated is merely "nice to have"
    instead of a hard requirement for probing, let's disable it on all
    LG boxes instead of trying to hunt down particular models.
    
    This change is prompted by patches trying to add "LG Electronics"/"ROCKY"
    and "LG Electronics"/"LW60-F27B" to the DMI list.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=77051
    
    Reported-by: Jaime Velasco Juan <jsagarribay@gmail.com>
    Reported-by: Georgios Tsalikis <georgios@tsalikis.net>
    Tested-by: Jaime Velasco Juan <jsagarribay@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3148dd711b30f75e0b7904d2e84247a07d60f935
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Sep 8 14:39:52 2014 -0700

    Input: elantech - fix detection of touchpad on ASUS s301l
    
    commit 271329b3c798b2102120f5df829071c211ef00ed upstream.
    
    Adjust Elantech signature validation to account fo rnewer models of
    touchpads.
    
    Reported-and-tested-by: Màrius Monton <marius.monton@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f68cd1d88e6cb3d07af440b97ac7d17d15deac8a
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sat Aug 30 13:51:06 2014 -0700

    Input: synaptics - add support for ForcePads
    
    commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream.
    
    ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
    physical buttons, instead they generate primary button click when user
    presses somewhat hard on the surface of the touchpad. Unfortunately they
    also report primary button click whenever there are 2 or more contacts
    on the pad, messing up all multi-finger gestures (2-finger scrolling,
    multi-finger tapping, etc). To cope with this behavior we introduce a
    delay (currently 50 msecs) in reporting primary press in case more
    contacts appear.
    
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0d82a3711b9f33151e44768b3de24216061a9339
Author: John Sung <penmount.touch@gmail.com>
Date:   Tue Sep 9 10:06:51 2014 -0700

    Input: serport - add compat handling for SPIOCSTYPE ioctl
    
    commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream.
    
    When running a 32-bit inputattach utility in a 64-bit system, there will be
    error code "inputattach: can't set device type". This is caused by the
    serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl
    fails.
    
    Signed-off-by: John Sung <penmount.touch@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3fc612d8552ff7c08f8e176a515a25019e7972a0
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Aug 28 11:09:31 2014 -0400

    dm crypt: fix access beyond the end of allocated space
    
    commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed upstream.
    
    The DM crypt target accesses memory beyond allocated space resulting in
    a crash on 32 bit x86 systems.
    
    This bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 "dm
    crypt: use async crypto").  However, this bug was masked by the fact
    that kmalloc rounds the size up to the next power of two.  This bug
    wasn't exposed until 3.17-rc1 commit 298a9fa08a ("dm crypt: use per-bio
    data").  By switching to using per-bio data there was no longer any
    padding beyond the end of a dm-crypt allocated memory block.
    
    To minimize allocation overhead dm-crypt puts several structures into one
    block allocated with kmalloc.  The block holds struct ablkcipher_request,
    cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))),
    struct dm_crypt_request and an initialization vector.
    
    The variable dmreq_start is set to offset of struct dm_crypt_request
    within this memory block.  dm-crypt allocates the block with this size:
    cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size.
    
    When accessing the initialization vector, dm-crypt uses the function
    iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq
    + 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1).
    
    dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request
    structure.  However, when dm-crypt accesses the initialization vector, it
    takes a pointer to the end of dm_crypt_request, aligns it, and then uses
    it as the initialization vector.  If the end of dm_crypt_request is not
    aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the
    alignment causes the initialization vector to point beyond the allocated
    space.
    
    Fix this bug by calculating the variable iv_size_padding and adding it
    to the allocated size.
    
    Also correct the alignment of dm_crypt_request.  struct dm_crypt_request
    is specific to dm-crypt (it isn't used by the crypto subsystem at all),
    so it is aligned on __alignof__(struct dm_crypt_request).
    
    Also align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is
    aligned as if the block was allocated with kmalloc.
    
    Reported-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
    Tested-by: Milan Broz <gmazyland@gmail.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 830f9d143134c0573debdd6c7c82a6d26f2d364d
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Fri Sep 5 03:11:28 2014 +0300

    dm cache: fix race causing dirty blocks to be marked as clean
    
    commit 40aa978eccec61347cd47b97c598df49acde8be5 upstream.
    
    When a writeback or a promotion of a block is completed, the cell of
    that block is removed from the prison, the block is marked as clean, and
    the clear_dirty() callback of the cache policy is called.
    
    Unfortunately, performing those actions in this order allows an incoming
    new write bio for that block to come in before clearing the dirty status
    is completed and therefore possibly causing one of these two scenarios:
    
    Scenario A:
    
    Thread 1                      Thread 2
    cell_defer()                  .
    - cell removed from prison    .
    - detained bios queued        .
    .                             incoming write bio
    .                             remapped to cache
    .                             set_dirty() called,
    .                               but block already dirty
    .                               => it does nothing
    clear_dirty()                 .
    - block marked clean          .
    - policy clear_dirty() called .
    
    Result: Block is marked clean even though it is actually dirty. No
    writeback will occur.
    
    Scenario B:
    
    Thread 1                      Thread 2
    cell_defer()                  .
    - cell removed from prison    .
    - detained bios queued        .
    clear_dirty()                 .
    - block marked clean          .
    .                             incoming write bio
    .                             remapped to cache
    .                             set_dirty() called
    .                             - block marked dirty
    .                             - policy set_dirty() called
    - policy clear_dirty() called .
    
    Result: Block is properly marked as dirty, but policy thinks it is clean
    and therefore never asks us to writeback it.
    This case is visible in "dmsetup status" dirty block count (which
    normally decreases to 0 on a quiet device).
    
    Fix these issues by calling clear_dirty() before calling cell_defer().
    Incoming bios for that block will then be detained in the cell and
    released only after clear_dirty() has completed, so the race will not
    occur.
    
    Found by inspecting the code after noticing spurious dirty counts
    (scenario B).
    
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5dbe54b25d46735fdbdabbd3fb4c3ec0363476dd
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Aug 26 09:05:36 2014 -0600

    block: Fix dev_t minor allocation lifetime
    
    commit 2da78092dda13f1efd26edbbf99a567776913750 upstream.
    
    Releases the dev_t minor when all references are closed to prevent
    another device from acquiring the same major/minor.
    
    Since the partition's release may be invoked from call_rcu's soft-irq
    context, the ext_dev_idr's mutex had to be replaced with a spinlock so
    as not so sleep.
    
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7e64965b5b2d7a18f441eb189a56b4b14330a528
Author: Tejun Heo <tj@kernel.org>
Date:   Sat Sep 13 04:14:30 2014 +0900

    workqueue: apply __WQ_ORDERED to create_singlethread_workqueue()
    
    commit e09c2c295468476a239d13324ce9042ec4de05eb upstream.
    
    create_singlethread_workqueue() is a compat interface for single
    threaded workqueue which maps to ordered workqueue w/ rescuer in the
    current implementation.  create_singlethread_workqueue() currently
    implemented by invoking alloc_workqueue() w/ appropriate parameters.
    
    8719dceae2f9 ("workqueue: reject adjusting max_active or applying
    attrs to ordered workqueues") introduced __WQ_ORDERED to protect
    ordered workqueues against dynamic attribute changes which can break
    ordering guarantees but forgot to apply it to
    create_singlethread_workqueue().  This in itself is okay as nobody
    currently uses dynamic attribute change on workqueues created with
    create_singlethread_workqueue().
    
    However, 4c16bd327c ("workqueue: implement NUMA affinity for unbound
    workqueues") broke singlethreaded guarantee for ordered workqueues
    through allocating a separate pool_workqueue on each NUMA node by
    default.  A later change 8a2b75384444 ("workqueue: fix ordered
    workqueues in NUMA setups") fixed it by allocating only one global
    pool_workqueue if __WQ_ORDERED is set.
    
    Combined, the __WQ_ORDERED omission in create_singlethread_workqueue()
    became critical breaking its single threadedness and ordering
    guarantee.
    
    Let's make create_singlethread_workqueue() wrap
    alloc_ordered_workqueue() instead so that it inherits __WQ_ORDERED and
    can implicitly track future ordered_workqueue changes.
    
    v2: I missed that __WQ_ORDERED now protects against pwq splitting
        across NUMA nodes and incorrectly described the patch as a
        nice-to-have fix to protect against future dynamic attribute
        usages.  Oleg pointed out that this is actually a critical
        breakage due to 8a2b75384444 ("workqueue: fix ordered workqueues
        in NUMA setups").
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Mike Anderson <mike.anderson@us.ibm.com>
    Cc: Oleg Nesterov <onestero@redhat.com>
    Cc: Gustavo Luiz Duarte <gduarte@redhat.com>
    Cc: Tomas Henzl <thenzl@redhat.com>
    Fixes: 4c16bd327c ("workqueue: implement NUMA affinity for unbound workqueues")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 46b1344d7e441ab4d93f12519d4612fcfe9f26db
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sun Aug 31 22:11:11 2014 +0300

    Revert "iwlwifi: dvm: don't enable CTS to self"
    
    commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream.
    
    This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd.
    
    This commit caused packet loss.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 93dea67335cdc92e428f1745ee491baf6abb456d
Author: Mike Christie <michaelc@cs.wisc.edu>
Date:   Wed Sep 3 00:00:39 2014 -0500

    SCSI: libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
    
    commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream.
    
    This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
    This function is used by iscsi drivers and userspace to send iscsi PDUs/
    commands. For login commands, we have a set buffer size. For all other
    commands we do not support data buffers.
    
    This was reported by Dan Carpenter here:
    http://www.spinics.net/lists/linux-scsi/msg66838.html
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4396eb3041acad26c79f1732367881a078bbfb86
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Sep 1 20:27:29 2014 +0300

    NFC: microread: Potential overflows in microread_target_discovered()
    
    commit d07f1e8600ccb885c8f4143402b8912f7d827bcb upstream.
    
    Smatch says that skb->data is untrusted so we need to check to make sure
    that the memcpy() doesn't overflow.
    
    Fixes: cfad1ba87150 ('NFC: Initial support for Inside Secure microread')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d3ef35dde12c1fd335bb9b87ca4478fa15b5f1bb
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Sep 17 11:45:17 2014 -0700

    iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid
    
    commit b53b0d99d6fbf7d44330395349a895521cfdbc96 upstream.
    
    This patch fixes a bug in iscsit_logout_post_handler_diffcid() where
    a pointer used as storage for list_for_each_entry() was incorrectly
    being used to determine if no matching entry had been found.
    
    This patch changes iscsit_logout_post_handler_diffcid() to key off
    bool conn_found to determine if the function needs to exit early.
    
    Reported-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit de962cfb46d31cd7730a596ff5abbcc740bd9070
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 2 17:49:54 2014 -0400

    iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure
    
    commit 8ae757d09c45102b347a1bc2867f54ffc1ab8fda upstream.
    
    In iscsi_copy_param_list() a failed iscsi_param_list memory allocation
    currently invokes iscsi_release_param_list() to cleanup, and will promptly
    trigger a NULL pointer dereference.
    
    Instead, go ahead and return for the first iscsi_copy_param_list()
    failure case.
    
    Found by coverity.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f0d84efb3fdcf10a7181cd64fa5fdfb9e7fed3d2
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Wed Jul 2 16:19:25 2014 +0300

    Target/iser: Don't put isert_conn inside disconnected handler
    
    commit 0fc4ea701fcf5bc51ace4e288af5be741465f776 upstream.
    
    disconnected_handler is invoked on several CM events (such
    as DISCONNECTED, DEVICE_REMOVAL, TIMEWAIT_EXIT...). Since
    multiple  events can occur while before isert_free_conn is
    invoked, we might put all isert_conn references and free
    the connection too early.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f6dd2a9321825e8f90a11306cab39000f3809659
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Wed Jul 2 16:19:24 2014 +0300

    Target/iser: Get isert_conn reference once got to connected_handler
    
    commit c2f88b17a1d97ca4ecd96cc22333a7a4f1407d39 upstream.
    
    In case the connection didn't reach connected state, disconnected
    handler will never be invoked thus the second kref_put on
    isert_conn will be missing.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e97a9d734d5501ade4a710f986bf5a040d9149d0
Author: Johannes Pointner <johannes.pointner@gmail.com>
Date:   Mon Aug 25 09:04:00 2014 +0100

    iio:inkern: fix overwritten -EPROBE_DEFER in of_iio_channel_get_by_name
    
    commit 872687f626e033b4ddfaec1e410057cfc6636d77 upstream.
    
    Fixes: a2c12493ed7e ('iio: of_iio_channel_get_by_name() returns non-null pointers for error legs')
    
    which improperly assumes that of_iio_channel_get_by_name must always
    return NULL and thus now hides -EPROBE_DEFER.
    
    Signed-off-by: Johannes Pointner <johannes.pointner@br-automation.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cf7be26dc739221597b2881a0fc8c417227914ca
Author: Denis CIOCCA <denis.ciocca@st.com>
Date:   Thu Oct 9 13:55:00 2014 +0100

    iio:magnetometer: bugfix magnetometers gain values
    
    commit a31d0928999fbf33b3a6042e8bcb7b7f7e07d094 upstream.
    
    This patch fix gains values. The first driver was designed using
    engineering samples, in mass production the values are changed.
    
    Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a9900d507bb1125dde70c8ec1fcf7427594dcba9
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: adc: ad_sigma_delta: Fix indio_dev->trig assignment
    
    commit 9e5846be33277802c0c76e5c12825d0e4d27f639 upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bf9e42d8a897732a9c1879816d7c678c307799cf
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: st_sensors: Fix indio_dev->trig assignment
    
    commit f0e84acd7056e6d7ade551c6439531606ae30a46 upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d3d64e7ad87f13dcd40b6124e2e32c68a1df5478
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: meter: ade7758: Fix indio_dev->trig assignment
    
    commit 0495081179212b758775df752e657ea71dcae020 upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a7e734403a9f6e1dd02d07195b0210241f1abe62
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: inv_mpu6050: Fix indio_dev->trig assignment
    
    commit b07e3b3850b2e1f09c19f54d3ed7210d9f529e2c upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b93348781490f2968f415988a182f49329048b24
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: gyro: itg3200: Fix indio_dev->trig assignment
    
    commit 0b4dce2ee694a991ef38203ec5ff91a738518cb3 upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fe5cb10c640589bfa4597558704852d963624c10
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: hid_sensor_hub: Fix indio_dev->trig assignment
    
    commit 55a6f9ddfdea0d2d343cd1b39baf8aa752664b6e upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9aea83e499ec3fd2af2b658834e27fe697560123
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio: accel: bma180: Fix indio_dev->trig assignment
    
    commit 0668a4e4d297328ce08b44d91d160537596115e2 upstream.
    
    This can result in wrong reference count for trigger device, call
    iio_trigger_get to increment reference.
    Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
    with Jonathan.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0735fe8ac425e749ba6417eb95ee194b8100a393
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Aug 22 21:48:00 2014 +0100

    iio:trigger: modify return value for iio_trigger_get
    
    commit f153566570fb9e32c2f59182883f4f66048788fb upstream.
    
    Instead of a void function, return the trigger pointer.
    
    Whilst not in of itself a fix, this makes the following set of
    7 fixes cleaner than they would otherwise be.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 40cd8b4513507a0f03614c8821b08543e573ef00
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Wed Oct 30 22:48:00 2013 +0000

    iio: hid_Sensors: fix crash during trigger unregister
    
    commit ec7f68e07bf10198717b7824c78201b46bbf1956 upstream.
    
    We can't store the trigger instance created by iio_trigger_alloc, in
    trig field of iio_device structure. This needs to be stored in the
    driver private data. Othewise it can result in crash during module
    unload. Hence created a trig_ptr in the common data structure
    for each HID sensor IIO driver and storing here.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0fc1b58e1d892491ede584fe82041056a68d2438
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Thu Sep 4 10:52:53 2014 +0300

    ASoC: davinci-mcasp: Correct rx format unit configuration
    
    commit fe0a29e163a5d045c73faab682a8dac71c2f8012 upstream.
    
    In case of capture we should not use rotation. The reverse and mask is
    enough to get the data align correctly from the bus to MCU:
    Format	  data from bus    after reverse (XRBUF)
    S16_LE:  |LSB|MSB|xxx|xxx|  |xxx|xxx|MSB|LSB|
    S24_3LE: |LSB|DAT|MSB|xxx|  |xxx|MSB|DAT|LSB|
    S24_LE:  |LSB|DAT|MSB|xxx|  |xxx|MSB|DAT|LSB|
    S32_LE:  |LSB|DAT|DAT|MSB|  |MSB|DAT|DAT|LSB|
    
    With this patch all supported formats will work for playback and capture.
    
    Reported-by: Jyri Sarha <jsarha@ti.com> (broken S24_3LE capture)
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c247cd22d37f4c2a8fe176d0065c1adfc71190cc
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Sep 24 17:56:17 2014 +0200

    shmem: fix nlink for rename overwrite directory
    
    commit b928095b0a7cff7fb9fcf4c706348ceb8ab2c295 upstream.
    
    If overwriting an empty directory with rename, then need to drop the extra
    nlink.
    
    Test prog:
    
    #include <stdio.h>
    #include <fcntl.h>
    #include <err.h>
    #include <sys/stat.h>
    
    int main(void)
    {
    	const char *test_dir1 = "test-dir1";
    	const char *test_dir2 = "test-dir2";
    	int res;
    	int fd;
    	struct stat statbuf;
    
    	res = mkdir(test_dir1, 0777);
    	if (res == -1)
    		err(1, "mkdir(\"%s\")", test_dir1);
    
    	res = mkdir(test_dir2, 0777);
    	if (res == -1)
    		err(1, "mkdir(\"%s\")", test_dir2);
    
    	fd = open(test_dir2, O_RDONLY);
    	if (fd == -1)
    		err(1, "open(\"%s\")", test_dir2);
    
    	res = rename(test_dir1, test_dir2);
    	if (res == -1)
    		err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2);
    
    	res = fstat(fd, &statbuf);
    	if (res == -1)
    		err(1, "fstat(%i)", fd);
    
    	if (statbuf.st_nlink != 0) {
    		fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink);
    		return 1;
    	}
    
    	return 0;
    }
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6e8ce280a960eac08586cc762fc64b1aa90fe955
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Mon Aug 18 10:41:36 2014 +0100

    xen/manage: Always freeze/thaw processes when suspend/resuming
    
    commit 61a734d305e16944b42730ef582a7171dc733321 upstream.
    
    Always freeze processes when suspending and thaw processes when resuming
    to prevent a race noticeable with HVM guests.
    
    This prevents a deadlock where the khubd kthread (which is designed to
    be freezable) acquires a usb device lock and then tries to allocate
    memory which requires the disk which hasn't been resumed yet.
    Meanwhile, the xenwatch thread deadlocks waiting for the usb device
    lock.
    
    Freezing processes fixes this because the khubd thread is only thawed
    after the xenwatch thread finishes resuming all the devices.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a70da19380b16c737b3d2a663ec1239dfa45be79
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Tue Aug 19 16:19:35 2014 +0200

    KVM: s390/mm: try a cow on read only pages for key ops
    
    commit ab3f285f227fec62868037e9b1b1fd18294a83b8 upstream.
    
    The PFMF instruction handler  blindly wrote the storage key even if
    the page was mapped R/O in the host. Lets try a COW before continuing
    and bail out in case of errors.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 205acdd63470421d986f4f46b378e78dcdf4aedd
Author: Mark Brown <broonie@linaro.org>
Date:   Wed Aug 27 13:09:12 2014 +0100

    regmap: Don't attempt block writes when syncing cache on single_rw devices
    
    commit 5c1ebe7f73f9166893c3459915db8a09d6d1d715 upstream.
    
    If the device can't support block writes then don't attempt to use raw
    syncing which will automatically generate block writes for adjacent
    registers, use the existing _single() block syncing implementation.
    
    Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 03d0cb29f14ec811567fd9c838c8a085c7980e69
Author: Mark Brown <broonie@linaro.org>
Date:   Tue Aug 26 12:12:17 2014 +0100

    regmap: Fix handling of volatile registers for format_write() chips
    
    commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream.
    
    A previous over-zealous factorisation of code means that we only treat
    registers as volatile if they are readable. For most devices this is fine
    since normally most registers can be read and volatility implies
    readability but for format_write() devices where there is no readback from
    the hardware and we use volatility to mean simply uncacheability this means
    that we end up treating all registers as cacheble.
    
    A bigger refactoring of the code to clarify this is in order but as a fix
    make a minimal change and only check readability when checking volatility
    if there is no format_write() operation defined for the device.
    
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Tested-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2eca54d0920a9beff88cbbdc58176559ac7644a5
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Tue Sep 16 15:55:12 2014 +0100

    MIPS: mcount: Adjust stack pointer for static trace in MIPS32
    
    commit 8a574cfa2652545eb95595d38ac2a0bb501af0ae upstream.
    
    Every mcount() call in the MIPS 32-bit kernel is done as follows:
    
    [...]
    move at, ra
    jal _mcount
    addiu sp, sp, -8
    [...]
    
    but upon returning from the mcount() function, the stack pointer
    is not adjusted properly. This is explained in details in 58b69401c797
    (MIPS: Function tracer: Fix broken function tracing).
    
    Commit ad8c396936e3 ("MIPS: Unbreak function tracer for 64-bit kernel.)
    fixed the stack manipulation for 64-bit but it didn't fix it completely
    for MIPS32.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7792/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8cc50e190b4cd308975d3f6886c8a49f4f5c5ce3
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sun Jul 20 19:58:23 2014 +0200

    MIPS: ZBOOT: add missing <linux/string.h> include
    
    commit 29593fd5a8149462ed6fad0d522234facdaee6c8 upstream.
    
    Commit dc4d7b37 (MIPS: ZBOOT: gather string functions into string.c)
    moved the string related functions into a separate file, which might
    cause the following build error, depending on the configuration:
    
    | CC      arch/mips/boot/compressed/decompress.o
    | In file included from linux/arch/mips/boot/compressed/../../../../lib/decompress_unxz.c:234:0,
    |                  from linux/arch/mips/boot/compressed/decompress.c:67:
    | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'fill_temp':
    | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration]
    | cc1: some warnings being treated as errors
    | linux/scripts/Makefile.build:308: recipe for target 'arch/mips/boot/compressed/decompress.o' failed
    | make[6]: *** [arch/mips/boot/compressed/decompress.o] Error 1
    | linux/arch/mips/Makefile:308: recipe for target 'vmlinuz' failed
    
    It does not fail with the standard configuration, as when
    CONFIG_DYNAMIC_DEBUG is not enabled <linux/string.h> gets included in
    include/linux/dynamic_debug.h. There might be other ways for it to
    get indirectly included.
    
    We can't add the include directly in xz_dec_stream.c as some
    architectures might want to use a different version for the boot/
    directory (see for example arch/x86/boot/string.h).
    
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7420/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 07eb809169efcacdca034d930581cad5cc06d798
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Thu Sep 25 11:56:19 2014 +0100

    ARM: 8165/1: alignment: don't break misaligned NEON load/store
    
    commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream.
    
    The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
    instructions (where the optional alignment hint is given but incorrect)
    as LDR/STR, leading to register corruption. Detect these and correctly
    treat them as unhandled, so that userspace gets the fault it expects.
    
    Reported-by: Simon Hosie <simon.hosie@arm.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3443c6fd1de2485cbd3e94ac35e54586a8ecc69f
Author: Nathan Lynch <nathan_lynch@mentor.com>
Date:   Thu Sep 11 02:49:08 2014 +0100

    ARM: 8148/1: flush TLS and thumbee register state during exec
    
    commit fbfb872f5f417cea48760c535e0ff027c88b507a upstream.
    
    The TPIDRURO and TPIDRURW registers need to be flushed during exec;
    otherwise TLS information is potentially leaked.  TPIDRURO in
    particular needs careful treatment.  Since flush_thread basically
    needs the same code used to set the TLS in arm_syscall, pull that into
    a common set_tls helper in tls.h and use it in both places.
    
    Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
    its save slot in thread_info isn't right as there is no guarantee
    that a thread switch will occur before the new program runs.  Just
    setting the register directly is sufficient.
    
    Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 132f8be98a83c38b1c63a8962ce63c31e28fd763
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Mon Sep 1 17:14:29 2014 +0100

    ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs
    
    commit a040803a9d6b8c1876d3487a5cb69602ebcbb82c upstream.
    
    Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
    going down") the ARM interrupt migration code on cpu offline calls
    irqchip.irq_set_affinity() with the argument force=true. At the point
    of this change the argument had no effect because it was not used by
    any interrupt chip driver and there was no semantics defined.
    
    This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
    affinity of interrupts") which made the force argument useful to route
    interrupts to not yet online cpus without checking the target cpu
    against the cpu online mask. The following commit ffde1de64012
    ("irqchip: gic: Support forced affinity setting") implemented this for
    the GIC interrupt controller.
    
    As a consequence the ARM cpu offline irq migration fails if CPU0 is
    offlined, because CPU0 is still set in the affinity mask and the
    validataion against cpu online mask is skipped to the force argument
    being true. The following first_cpu(mask) selection always selects
    CPU0 as the target.
    
    Solve the issue by calling irq_set_affinity() with force=false from
    the CPU offline irq migration code so the GIC driver validates the
    affinity mask against CPU online mask and therefore removes CPU0 from
    the possible target candidates.
    
    Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
    locks up as the IRQs are not migrated away from CPU0.
    
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c66b368da7a801270258026a91418a7053faac88
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Aug 15 12:11:49 2014 +0100

    ARM: 8128/1: abort: don't clear the exclusive monitors
    
    commit 85868313177700d20644263a782351262d2aff84 upstream.
    
    The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
    upon entry to the kernel, but this is redundant:
    
      - We clear the monitors on every exception return since commit
        200b812d0084 ("Clear the exclusive monitor when returning from an
        exception"), so this is not necessary to ensure the monitors are
        cleared before returning from a fault handler.
    
      - Any dummy STREX will target a temporary scratch area in memory, and
        may succeed or fail without corrupting useful data. Its status value
        will not be used.
    
      - Any other STREX in the kernel must be preceded by an LDREX, which
        will initialise the monitors consistently and will not depend on the
        earlier state of the monitors.
    
    Therefore we have no reason to care about the initial state of the
    exclusive monitors when a data abort is taken, and clearing the monitors
    prior to exception return (as we already do) is sufficient.
    
    This patch removes the redundant clearing of the exclusive monitors from
    the early abort handlers.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a120ef8646dd4486d3f5c20469b189ef58aa55e5
Author: Jorge A. Ventura <jorge.araujo.ventura@gmail.com>
Date:   Sat Aug 9 16:06:58 2014 -0500

    spi/omap-mcspi: Fix the spi task hangs waiting dma_rx
    
    commit 3d0763c006f8da1b44a9f5f9a21187f5b8f674f4 upstream.
    
    The spi hangs waiting the completion of omap2_mcspi_rx_callback.
    
    Signed-off-by: Jorge A. Ventura <jorge.araujo.ventura@gmail.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f3a1710548df4e877c2ec66991fa9a9541317a31
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Thu Sep 18 11:51:32 2014 -0400

    NFSv4: Fix another bug in the close/open_downgrade code
    
    commit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream.
    
    James Drew reports another bug whereby the NFS client is now sending
    an OPEN_DOWNGRADE in a situation where it should really have sent a
    CLOSE: the client is opening the file for O_RDWR, but then trying to
    do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec.
    
    Reported-by: James Drews <drews@engr.wisc.edu>
    Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu
    Fixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...)
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c6365a41b6f7fb99458f9b6a4ea76f0f67b345cd
Author: Steve Dickson <steved@redhat.com>
Date:   Thu Sep 18 09:13:17 2014 -0400

    NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists()
    
    commit 080af20cc945d110f9912d01cf6b66f94a375b8d upstream.
    
    There is a race between nfs4_state_manager() and
    nfs_server_remove_lists() that happens during a nfsv3 mount.
    
    The v3 mount notices there is already a supper block so
    nfs_server_remove_lists() called which uses the nfs_client_lock
    spin lock to synchronize access to the client list.
    
    At the same time nfs4_state_manager() is running through
    the client list looking for work to do, using the same
    lock. When nfs4_state_manager() wins the race to the
    list, a v3 client pointer is found and not ignored
    properly which causes the panic.
    
    Moving some protocol checks before the state checking
    avoids the panic.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ab100e044866897de87b9feb5ac819c1ca2f1006
Author: Olav Haugan <ohaugan@codeaurora.org>
Date:   Mon Aug 4 19:01:02 2014 +0100

    iommu/arm-smmu: fix programming of SMMU_CBn_TCR for stage 1
    
    commit 1fc870c7efa364862c3bc792cfbdb38afea26742 upstream.
    
    Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it
    is only applicable to stage-2 context banks.
    
    This patch ensures that we don't set the reserved TCR bits for stage-1
    translations.
    
    Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 131d24d238b2072982068040d902a2b3a5f26711
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Thu Sep 4 15:13:39 2014 +0800

    ACPI / RTC: Fix CMOS RTC opregion handler accesses to wrong addresses
    
    commit 9389f46e9782ea5e56fbd7b2e59ba7c08f3ba86b upstream.
    
    The value64 parameter is an u64 point that used to transfer the value
    for write to CMOS, or used to return the value that's read from CMOS.
    
    The value64 is an u64 point, so don't need get address again. It causes
    acpi_cmos_rtc_space_handler always return 0 to reader and didn't write
    expected value to CMOS.
    
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 72faad48616b48ef4073963497a0a025d7d7d784
Author: Felipe Balbi <balbi@ti.com>
Date:   Wed Sep 3 16:42:57 2014 -0500

    usb: dwc3: omap: fix ordering for runtime pm calls
    
    commit 81a60b7f5c143ab3cdcd9943c9b4b7c63c32fc31 upstream.
    
    we don't to gate clocks until our children are
    done with their remove path.
    
    Fixes: af310e9 (usb: dwc3: omap: use runtime API's to enable clocks)
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 84694ab9297ba8c77c91caf705dde7860dc5f3f2
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Sep 17 11:23:54 2014 -0400

    USB: EHCI: unlink QHs even after the controller has stopped
    
    commit 7312b5ddd47fee2356baa78c5516ef8e04eed452 upstream.
    
    Old code in ehci-hcd tries to expedite disabling endpoints after the
    controller has stopped, by destroying the endpoint's associated QH
    without first unlinking the QH.  This was necessary back when the
    driver wasn't so careful about keeping track of the controller's
    state.
    
    But now we are careful about it, and the driver knows that when the
    controller isn't running, no unlinking delay is needed.  Furthermore,
    skipping the unlink step will trigger a BUG() in qh_destroy() when the
    preceding QH is released, because the link pointer will be non-NULL.
    
    Removing the lines that skip the unlinking step and go directly to
    QH_STATE_IDLE fixes the problem.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
    Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0cded8f59fb11f836abd919c3e9ff089c51845ed
Author: Mark <markk@clara.co.uk>
Date:   Wed Sep 17 19:15:43 2014 +0100

    USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters
    
    commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream.
    
    This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-
    SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The
    US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI
    chain to be accessed. Without it only the (single) device with SCSI ID 0
    can be used.
    
    The standalone converter sold by Entrega had model number U1-SC25. Xircom
    acquired Entrega and re-branded the product line PortGear. The PortGear USB
    to SCSI Converter (model PGSCSI) is internally identical to the Entrega
    product, but later models may use a different USB ID. The Entrega-branded
    units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and
    Macintosh drivers also support 085A:0028.
    
    Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac
    (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as
    a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may
    have initially used the same ID as the standalone U1-SC25 (1645:0007), but
    later production used 085A:0026.
    
    My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133
    probably also exist.
    
    This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows
    driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I
    couldn't find any mention of that actually existing in the wild; perhaps it
    was cancelled before release?
    
    Signed-off-by: Mark Knibbs <markk@clara.co.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 22630f7c518defb349c84df760736b9df170a2ee
Author: Mark <markk@clara.co.uk>
Date:   Tue Sep 16 16:51:41 2014 +0100

    USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter
    
    commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream.
    
    Hi,
    
    The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.
    iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM
    Microsystems chips. Only the connectors differ; both have the same USB ID.
    The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other
    than 0.
    
    I don't have one of these, but based on the other entries for Shuttle/
    SCM-based converters this patch is very likely correct. I used 0x0000 and
    0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
    bcdDevice value the products use.
    
    Signed-off-by: Mark Knibbs <markk@clara.co.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a527acbac993c988d4e7d7bde1c9a78afb145547
Author: Mark <markk@clara.co.uk>
Date:   Tue Sep 16 16:22:50 2014 +0100

    USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter
    
    commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream.
    
    The Adaptec USBConnect 2000 is another SCSI-USB converter which uses
    Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is
    required to use SCSI devices with ID other than 0.
    
    I don't have a USBConnect 2000, but based on the other entries for Shuttle/
    SCM-based converters this patch is very likely correct. I used 0x0000 and
    0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
    bcdDevice value the product uses.
    
    Signed-off-by: Mark Knibbs <markk@clara.co.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 89ef9aa06b6adedd45dd4de4d0628fa2f810f38c
Author: Mark <markk@clara.co.uk>
Date:   Thu Sep 11 13:15:45 2014 +0100

    storage: Add single-LUN quirk for Jaz USB Adapter
    
    commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream.
    
    The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware
    seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/
    SCM chip set. However its firmware restricts it to only work with Jaz
    drives.
    
    On connecting the cable a message like this appears four times in the log:
     reset full speed USB device number 4 using uhci_hcd
    
    That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.
    
    Signed-off-by: Mark Knibbs <markk@clara.co.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ce87d01187860ea3d181bdb52bbdb9627b2d6886
Author: Joe Lawrence <joe.lawrence@stratus.com>
Date:   Wed Sep 10 15:07:50 2014 -0400

    usb: hub: take hub->hdev reference when processing from eventlist
    
    commit c605f3cdff53a743f6d875b76956b239deca1272 upstream.
    
    During surprise device hotplug removal tests, it was observed that
    hub_events may try to call usb_lock_device on a device that has already
    been freed. Protect the usb_device by taking out a reference (under the
    hub_event_lock) when hub_events pulls it off the list, returning the
    reference after hub_events is finished using it.
    
    Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
    Suggested-by: David Bulkow <david.bulkow@stratus.com> for using kref
    Suggested-by: Alan Stern <stern@rowland.harvard.edu> for placement
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b9ad4c44ea0c06f0f56bdab7857a824f7c496482
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Sep 11 13:55:50 2014 +0300

    xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices
    
    commit 96044694b8511bc2b04df0776b4ba295cfe005c0 upstream.
    
    Resuming from hibernate (S4) will restart and re-initialize xHC.
    The device contexts are freed and will be re-allocated later during device reset.
    
    Usb core will disable link pm in device resume before device reset, which will
    try to change the max exit latency, accessing the device contexts before they are re-allocated.
    
    There is no need to zero (disable) the max exit latency when disabling hw lpm
    for a freshly re-initialized xHC. So check that device context exists before
    doing anything. The max exit latency will be set again after device reset when usb core
    enables the link pm.
    
    Reported-by: Imre Deak <imre.deak@intel.com>
    Tested-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit adcf3f05c962eee62864d3bd61b0b7534cb7015a
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Sep 11 13:55:48 2014 +0300

    xhci: Fix null pointer dereference if xhci initialization fails
    
    commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream.
    
    If xhci initialization fails before the roothub bandwidth
    domains (xhci->rh_bw[i]) are allocated it will oops when
    trying to access rh_bw members in xhci_mem_cleanup().
    
    Reported-by: Manuel Reimer <manuel.reimer@gmx.de>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cd410f34b10e5e1b1581ceba98dd9d5cd3bdb259
Author: Felipe Balbi <balbi@ti.com>
Date:   Wed Aug 27 16:38:04 2014 -0500

    usb: host: xhci: fix compliance mode workaround
    
    commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream.
    
    Commit 71c731a (usb: host: xhci: Fix Compliance Mode
    on SN65LVP3502CP Hardware) implemented a workaround
    for a known issue with Texas Instruments' USB 3.0
    redriver IC but it left a condition where any xHCI
    host would be taken out of reset if port was placed
    in compliance mode and there was no device connected
    to the port.
    
    That condition would trigger a fake connection to a
    non-existent device so that usbcore would trigger a
    warm reset of the port, thus taking the link out of
    reset.
    
    This has the side-effect of preventing any xHCI host
    connected to a Linux machine from starting and running
    the USB 3.0 Electrical Compliance Suite because the
    port will mysteriously taken out of compliance mode
    and, thus, xHCI won't step through the necessary
    compliance patterns for link validation.
    
    This patch fixes the issue by just adding a missing
    check for XHCI_COMP_MODE_QUIRK inside
    xhci_hub_report_usb3_link_state() when PORT_CAS isn't
    set.
    
    This patch should be backported to all kernels containing
    commit 71c731a.
    
    Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware)
    Cc: Alexis R. Cortes <alexis.cortes@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 45e6399d8d9043a1530c6316cb5b4f0dd4672a9c
Author: Thomas Pugliese <thomas.pugliese@gmail.com>
Date:   Thu Aug 7 15:45:35 2014 -0500

    uwb: init beacon cache entry before registering uwb device
    
    commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream.
    
    Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in
    uwbd_dev_onair so that usermode will only see the device after it is
    properly initialized.  This fixes a kernel panic that can occur if
    usermode tries to access the IEs sysfs attribute of a UWB device before
    the driver has had a chance to set the beacon cache entry.
    
    Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit eb8377cd5f57568b66bd219b4d93a3844fca8a52
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Aug 18 18:33:11 2014 +0200

    USB: ftdi_sio: add support for NOVITUS Bono E thermal printer
    
    commit ee444609dbae8afee420c3243ce4c5f442efb622 upstream.
    
    Add device id for NOVITUS Bono E thermal printer.
    
    Reported-by: Emanuel Koczwara <poczta@emanuelkoczwara.pl>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit acd75242338af597ea0f320605b13585d3d840ed
Author: Taylor Braun-Jones <taylor.braun-jones@ge.com>
Date:   Thu Aug 7 14:25:06 2014 -0400

    USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device
    
    commit 9c491c372d677b6420e0f8c6361fe422791662cc upstream.
    
    Signed-off-by: Taylor Braun-Jones <taylor.braun-jones@ge.com>
    Cc: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 47122ba9afee15aef7d4f002ef79cb650ec1e157
Author: Ivan T. Ivanov <iivanov@mm-sol.com>
Date:   Thu Sep 11 08:19:00 2014 +0800

    usb: chipidea: msm: Initialize PHY on reset event
    
    commit 233c7daf4eecd1e992dc42591182cd4a892e687c upstream.
    
    Initialize USB PHY after every Link controller reset
    
    Cc: Tim Bird <tbird20d@gmail.com>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9d080074b4379a7680682e9c528ae383912cfb9e
Author: Ivan T. Ivanov <iivanov@mm-sol.com>
Date:   Thu Sep 11 08:18:59 2014 +0800

    usb: chipidea: msm: Use USB PHY API to control PHY state
    
    commit ea290056d7c46f7781ff13801048ed957b96d1a5 upstream.
    
    PHY drivers keep track of the current state of the hardware,
    so don't change PHY settings under it.
    
    Cc: Tim Bird <tbird20d@gmail.com>
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1f350eb627325daadbd4cea4cd473fb97f670a87
Author: Thierry Reding <treding@nvidia.com>
Date:   Mon Jul 21 13:37:37 2014 +0200

    usb: phy: tegra: Avoid use of sizeof(void)
    
    commit 9ce9ec95fb9b82e09b55a52f1bb8a362bf8f74d8 upstream.
    
    The PHY configuration is stored in an opaque "config" field, but when
    allocating the structure, its proper size needs to be known. In the case
    of UTMI, the proper structure is tegra_utmip_config of which a local
    variable already exists, so we can use that to obtain the size from.
    
    Fixes the following warning from the sparse checker:
    
    	drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using sizeof(void)
    
    Fixes: 81d5dfe6d8b3 (usb: phy: tegra: Read UTMIP parameters from device tree)
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c46330c23b5fa82f3b191746531506e3f8b5abe3
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Aug 28 15:08:16 2014 +0200

    USB: sierra: add 1199:68AA device ID
    
    commit 5b3da69285c143b7ea76b3b9f73099ff1093ab73 upstream.
    
    This VID:PID is used for some Direct IP devices behaving
    identical to the already supported 0F3D:68AA devices.
    
    Reported-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ce686571e9a909b39cc3c17b99abb164b2c04f1a
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Aug 28 14:11:23 2014 +0200

    USB: sierra: avoid CDC class functions on "68A3" devices
    
    commit 049255f51644c1105775af228396d187402a5934 upstream.
    
    Sierra Wireless Direct IP devices using the 68A3 product ID
    can be configured for modes including a CDC ECM class function.
    The known example uses interface numbers 12 and 13 for the ECM
    control and data interfaces respectively, consistent with CDC
    MBIM function interface numbering on other Sierra devices.
    
    It seems cleaner to restrict this driver to the ff/ff/ff
    vendor specific interfaces rather than increasing the already
    long interface number blacklist.  This should be more future
    proof if Sierra adds more class functions using interface
    numbers not yet in the blacklist.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8d54bc8ee74eb47423ca0b752532b2b6b9929979
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Aug 7 16:00:15 2014 +0200

    USB: zte_ev: remove duplicate Qualcom PID
    
    commit 754eb21c0bbbbc4b8830a9a864b286323b84225f upstream.
    
    Remove dublicate Qualcom PID 0x3197 which is already handled by the
    moto-modem driver since commit 6986a978eec7 ("USB: add new moto_modem
    driver for some Morotola phones").
    
    Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0eb88f075ddb03c2fb7cb8e1b4b52a8f6fb709ab
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Aug 7 16:00:14 2014 +0200

    USB: zte_ev: remove duplicate Gobi PID
    
    commit 95be5739588c56a9327e477aa0ba3c81c5cf8631 upstream.
    
    Remove dublicate Gobi PID 0x9008 which is already handled by the
    qcserial driver since commit f05932c0caf4 ("USB: qcserial: Add extra
    device IDs").
    
    Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit be4762c583702914ecc91b9d60bc539becf30456
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Aug 7 16:00:13 2014 +0200

    Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"
    
    commit 63a901c06e3c2c45bd601916fe04e870e9ccae1e upstream.
    
    This reverts commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE
    CDMA devices to zte_ev").
    
    Move the IDs of the devices that were previously driven by the option
    driver back to that driver.
    
    As several users have reported, the zte_ev driver is causing random
    disconnects as well as reconnect failures.
    
    A closer analysis of the zte_ev setup code reveals that it consists of
    standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE)
    but unfortunately fails to get some of those right. In particular, as
    reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears
    that the control requests lack the interface argument.
    
    Note that the zte_ev driver is based on code (once) distributed by ZTE
    that still appears to originally have been reverse-engineered and bolted
    onto the generic driver.
    
    Since line control is already handled properly by the option driver, and
    the SET/GET_LINE_CODING requests appears to be redundant (amounts to a
    SET 9600 8N1), this is a first step in ultimately removing the redundant
    zte_ev driver.
    
    Note that AC2726 had already been moved back to option, and that some
    IDs were in the device table of both drivers prior to the commit being
    reverted.
    
    Reported-by: Lei Liu <liu.lei78@zte.com.cn>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d6c05d3cf129ce9d160807c09ccbee9f45e049c5
Author: Brennan Ashton <bashton@brennanashton.com>
Date:   Wed Aug 6 08:46:44 2014 -0700

    USB: option: add VIA Telecom CDS7 chipset device id
    
    commit d77302739d900bbca5e901a3b7ac48c907ee6c93 upstream.
    
    This VIA Telecom baseband processor is used is used by by u-blox in both the
    FW2770 and FW2760 products and may be used in others as well.
    
    This patch has been tested on both of these modem versions.
    
    Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4ad8d53c777d5b48115b8cb9e73391ac434f9e60
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jul 29 14:14:55 2014 +0200

    USB: option: reduce interrupt-urb logging verbosity
    
    commit f0e4cba2534cd88476dff920727c81350130f3c5 upstream.
    
    Do not log normal interrupt-urb shutdowns as errors.
    
    The option driver has always been logging any nonzero interrupt-urb
    status as an error, including when the urb is killed during normal
    operation.
    
    Commit 9096f1fbba91 ("USB: usb_wwan: fix potential NULL-deref at
    resume") moved the interrupt urb submission from port probe and release
    to open and close, thus potentially increasing the number of these
    false-positive error messages dramatically.
    
    Reported-by: Ed Butler <ressy66@ausics.net>
    Tested-by: Ed Butler <ressy66@ausics.net>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3bff5350f7519673d203a49ee871b321ddfae414
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Aug 27 11:55:19 2014 +0200

    USB: serial: fix potential heap buffer overflow
    
    commit 5654699fb38512bdbfc0f892ce54fce75bdc2bab upstream.
    
    Make sure to verify the number of ports requested by subdriver to avoid
    writing beyond the end of fixed-size array in interface data.
    
    The current usb-serial implementation is limited to eight ports per
    interface but failed to verify that the number of ports requested by a
    subdriver (which could have been determined from device descriptors) did
    not exceed this limit.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9b2aef34ef9734422a4c42f1220fce62717a46ce
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Mon Aug 25 21:07:47 2014 -0700

    USB: sisusb: add device id for Magic Control USB video
    
    commit 5b6b80aeb21091ed3030b9b6aae597d81326f1aa upstream.
    
    I have a j5 create (JUA210) USB 2 video device and adding it device id
    to SIS USB video gets it to work.
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1fe534c90d6af20a2fa3e15e2c0079696c5cd10d
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Aug 27 11:55:18 2014 +0200

    USB: serial: fix potential stack buffer overflow
    
    commit d979e9f9ecab04c1ecca741370e30a8a498893f5 upstream.
    
    Make sure to verify the maximum number of endpoints per type to avoid
    writing beyond the end of a stack-allocated array.
    
    The current usb-serial implementation is limited to eight ports per
    interface but failed to verify that the number of endpoints of a certain
    type reported by a device did not exceed this limit.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3dbae95c6b00f048d16241065fa8daf0bb2d5325
Author: Greg KH <gregkh@linuxfoundation.org>
Date:   Fri Aug 15 15:22:21 2014 +0800

    USB: serial: pl2303: add device id for ztek device
    
    commit 91fcb1ce420e0a5f8d92d556d7008a78bc6ce1eb upstream.
    
    This adds a new device id to the pl2303 driver for the ZTEK device.
    
    Reported-by: Mike Chu <Mike-Chu@prolific.com.tw>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Johan Hovold <johan@kernel.org>

commit 9b9dbcf3bc9188dfd3691a48b34d6afa628474ea
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Jul 31 22:40:57 2014 +0400

    xtensa: fix a6 and a7 handling in fast_syscall_xtensa
    
    commit d1b6ba82a50cecf94be540a3a153aa89d97511a0 upstream.
    
    Remove restoring a6 on some return paths and instead modify and restore
    it in a single place, using symbolic name.
    Correctly restore a7 from PT_AREG7 in case of illegal a6 value.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ebd3eb22e54df555edb485a7dff8f57ac3e18b1e
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Jul 21 22:01:51 2014 +0400

    xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
    
    commit 7128039fe2dd3d59da9e4ffa036f3aaa3ba87b9f upstream.
    
    Current definition of TLBTEMP_BASE_2 is always 32K above the
    TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP
    region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER)
    to determine TLBTEMP region where the fault happened. The size of the
    TLBTEMP region is also checked incorrectly: not 64K, but twice data
    cache way size (whicht may as well be less than the instruction cache
    way size).
    
    Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size.
    Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or
    the instruction cache way size, and use it to determine if the second
    level TLB miss occured in the TLBTEMP region.
    
    Practical occurence of page faults in the TLBTEMP area is extremely
    rare, this code can be tested by deletion of all w[di]tlb instructions
    in the tlbtemp_mapping region.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8b44a092cac58f0d298e8c8e77a60f6f4d64a678
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Sun Jul 27 07:23:41 2014 +0400

    xtensa: fix access to THREAD_RA/THREAD_SP/THREAD_DS
    
    commit 52247123749cc3cbc30168b33ad8c69515c96d23 upstream.
    
    With SMP and a lot of debug options enabled task_struct::thread gets out
    of reach of s32i/l32i instructions with base pointing at task_struct,
    breaking build with the following messages:
    
      arch/xtensa/kernel/entry.S: Assembler messages:
      arch/xtensa/kernel/entry.S:1002: Error: operand 3 of 'l32i.n' has invalid value '1048'
      arch/xtensa/kernel/entry.S:1831: Error: operand 3 of 's32i.n' has invalid value '1040'
      arch/xtensa/kernel/entry.S:1832: Error: operand 3 of 's32i.n' has invalid value '1044'
    
    Change base to point to task_struct::thread in such cases.
    Don't use a10 in _switch_to to save/restore prev pointer as a2 is not
    clobbered.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5faa070614a1bfd3643dbf150d4a1193483dff15
Author: Alan Douglas <adouglas@cadence.com>
Date:   Wed Jul 23 14:06:40 2014 +0400

    xtensa: fix address checks in dma_{alloc,free}_coherent
    
    commit 1ca49463c44c970b1ab1d71b0f268bfdf8427a7e upstream.
    
    Virtual address is translated to the XCHAL_KSEG_CACHED region in the
    dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE
    range.
    
    Change check for end of the range from 'addr >= X' to 'addr > X - 1' to
    handle the case of X == 0.
    
    Replace 'if (C) BUG();' construct with 'BUG_ON(C);'.
    
    Signed-off-by: Alan Douglas <adouglas@cadence.com>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f5f0bec3dc92ccb31cb8d7193fc9442e24bdc7d0
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Sun Jul 20 03:38:53 2014 +0400

    xtensa: replace IOCTL code definitions with constants
    
    commit f61bf8e7d19e0a3456a7a9ed97c399e4353698dc upstream.
    
    This fixes userspace code that builds on other architectures but fails
    on xtensa due to references to structures that other architectures don't
    refer to. E.g. this fixes the following issue with python-2.7.8:
    
      python-2.7.8/Modules/termios.c:861:25: error: invalid application
         of 'sizeof' to incomplete type 'struct serial_multiport_struct'
         {"TIOCSERGETMULTI", TIOCSERGETMULTI},
      python-2.7.8/Modules/termios.c:870:25: error: invalid application
         of 'sizeof' to incomplete type 'struct serial_multiport_struct'
         {"TIOCSERSETMULTI", TIOCSERSETMULTI},
      python-2.7.8/Modules/termios.c:900:24: error: invalid application
         of 'sizeof' to incomplete type 'struct tty_struct'
         {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT},
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6d4933b6d7a84642bd4fe913be7182032e396e38
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Sep 23 10:20:13 2014 -0400

    drm/radeon/cik: use a separate counter for CP init timeout
    
    commit 370ce45b5986118fa496dddbcd7039e1aa1a418f upstream.
    
    Otherwise we may fail to init the second compute ring.
    
    Noticed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 07e6a67ac1cc5aa5a7cc00625170ba1ee566e5de
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Sep 18 10:23:04 2014 -0400

    drm/radeon: don't reset dma on r6xx-evergreen init
    
    commit c1789a2e66a4209fe5035eca11fdd729b2ffdd82 upstream.
    
    Otherwise we may lose the DMA golden settings which can
    lead to hangs, etc.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9186f7d58bca0f75d582998e4d93118ed7a8e379
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Sep 18 10:18:43 2014 -0400

    drm/radeon: don't reset sdma on CIK init
    
    commit 799028d5d85384cce140323be633c8d5f079193f upstream.
    
    Otherwise we may lose the DMA golden settings which can
    lead to hangs, etc.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 143dc0d324230a7489615b0143928dd0d7270674
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Sep 17 17:41:04 2014 -0400

    drm/radeon: don't reset dma on NI/SI init
    
    commit 31a25e2caf9367365fcb0e57fd8fa5a42e9b73e4 upstream.
    
    Otherwise we may lose the DMA golden settings which can
    lead to hangs, etc.
    
    bug:
    https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 05ca98f543e205fcb28d0d43853761c2e0ac3225
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 8 13:55:51 2014 -0400

    drm/radeon: add connector quirk for fujitsu board
    
    commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream.
    
    Vbios connector table lists non-existent VGA port.
    
    Bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=83184
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fadaf70f189f88cce6cd6448b33a2178453f5173
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 8 02:33:32 2014 -0400

    drm/radeon/dpm: set the thermal type properly for special configs
    
    commit ff4377924f7e587c61bcbc704eafecf6c7bd2e00 upstream.
    
    On systems with special thermal configurations make sure we make
    note of the thermal setup.  This is required for proper firmware
    configuration on these systems.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 501aa36c9ccd2bc12911fa2ba9d9136d70b02d40
Author: Oleg Chernovskiy <algonkvel@gmail.com>
Date:   Mon Aug 11 21:53:46 2014 +0400

    drm/radeon: Add missing lines to ci_set_thermal_temperature_range
    
    commit 6bce8d9772c1c606921a9c99e566eb14202f6669 upstream.
    
    Properly set the thermal min and max temp on CI.
    Otherwise, we end up setting the thermal ranges
    to 0 on resume and end up in the lowest power state.
    
    Signed-off-by: Oleg Chernovskiy <algonkvel@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c3dabf0cb5672e5931dc592f927991925c372d5b
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Thu Aug 28 11:53:23 2014 +0200

    drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
    
    commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.
    
    The code waiting for fifo idle was incorrect and could possibly spin
    forever under certain circumstances.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reported-by: Mark Sheldon <markshel@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Reivewed-by: Mark Sheldon <markshel@vmware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit eab07705c238b10ba23a22b53e4e8291c971447f
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Sep 10 12:07:54 2014 +0800

    drm/ast: AST2000 cannot be detected correctly
    
    commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream.
    
    Type error and cause AST2000 cannot be detected correctly
    
    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Reviewed-by: Egbert Eich <eich@suse.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c61d245219f5d719a5b8099f42c0ca95c55f48e6
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 8 17:43:01 2014 +0300

    drm/i915: Wait for vblank before enabling the TV encoder
    
    commit 7a98948f3b536ca9a077e84966ddc0e9f53726df upstream.
    
    The vblank waits in intel_tv_detect_type() are timing out for some
    reason. This is a regression caused removing seemingly useless vblank
    waits from the modeset seqeuence in:
    
     commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f
     Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
     Date:   Thu May 8 19:23:15 2014 +0300
    
        drm/i915: Kill vblank waits after pipe enable on gmch platforms
    
    So it turns out they weren't all entirely useless. Apparently the pipe
    has to go through one full frame before we enable the TV port. Add a
    vblank wait to intel_enable_tv() to make sure that happens.
    
    Another approach was attempted by placing the vblank wait just after
    enabling the port. The theory behind that attempt was that we need to
    let the port stay enabled for one full frame before disabling it again
    during load detection. But that didn't work, and we definitely must
    have the vblank wait before enabling the port.
    
    Cc: Alan Bartlett <ajb@elrepo.org>
    Tested-by: Alan Bartlett <ajb@elrepo.org>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 21b99c3bb0ca45540e47891815918a2b5daf0bea
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Sep 4 09:36:18 2014 +0200

    drm/i915: Fix EIO/wedged handling in gem fault handler
    
    commit 2232f0315c6688f5ff6b2067ea88d97542034873 upstream.
    
    In
    
    commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Thu Nov 15 17:17:22 2012 +0100
    
        drm/i915: clear up wedged transitions
    
    I've accidentally inverted the EIO/wedged handling in the fault
    handler: We want to return the EIO as a SIGBUS only if it's not
    because of the gpu having died, to prevent userspace from unduly
    dying.
    
    In my defence the comment right above is completely misleading, so fix
    both.
    
    v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO
    when swap-in fails.
    
    v3: Don't remove too much ... oops.
    
    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3d5b3eecee0dda3f6ca3bbe1a6b25941a218dcc6
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 27 18:41:19 2014 +0200

    drm/i915: Remove bogus __init annotation from DMI callbacks
    
    commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream.
    
    The __init annotations for the DMI callback functions are wrong as this
    code can be called even after the module has been initialized, e.g. like
    this:
    
      # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
      # modprobe i915
      # echo 1 > /sys/bus/pci/rescan
    
    The first command will remove the PCI device from the kernel's device
    list so the second command won't see it right away. But as it registers
    a PCI driver it'll see it on the third command. If the system happens to
    match one of the DMI table entries we'll try to call a function in long
    released memory and generate an Oops, at best.
    
    Fix this by removing the bogus annotation.
    
    Modpost should have caught that one but it ignores section reference
    mismatches from the .rodata section. :/
    
    Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
    Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
    Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Duncan Laurie <dlaurie@chromium.org>
    Cc: Jarod Wilson <jarod@redhat.com>
    Cc: Rusty Russell <rusty@rustcorp.com.au>	# Can modpost be fixed?
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit af16efcfa36e628be58efd7e0f81e6bf327355fa
Author: Filipe Brandenburger <filbranden@google.com>
Date:   Fri Aug 29 15:18:51 2014 -0700

    xattr: fix check for simultaneous glibc header inclusion
    
    commit bfcfd44cce2774f19daeb59fb4e43fc9aa80e7b8 upstream.
    
    The guard was introduced in commit ea1a8217b06b ("xattr: guard against
    simultaneous glibc header inclusion") but it is using #ifdef to check
    for a define that is either set to 1 or 0.  Fix it to use #if instead.
    
    * Without this patch:
    
      $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null
      include/uapi/linux/xattr.h:19:0: warning: "XATTR_CREATE" redefined [enabled by default]
       #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */
       ^
      /usr/include/x86_64-linux-gnu/sys/xattr.h:32:0: note: this is the location of the previous definition
       #define XATTR_CREATE XATTR_CREATE
       ^
    
    * With this patch:
    
      $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null
      (no warnings)
    
    Signed-off-by: Filipe Brandenburger <filbranden@google.com>
    Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Cc: Allan McRae <allan@archlinux.org>
    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 225bdf83cf1b47cc2d574cd8b7b7ce03a3b34641
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Aug 22 16:16:05 2014 -0400

    HID: logitech-dj: prevent false errors to be shown
    
    commit 5abfe85c1d4694d5d4bbd13ecc166262b937adf0 upstream.
    
    Commit "HID: logitech: perform bounds checking on device_id early
    enough" unfortunately leaks some errors to dmesg which are not real
    ones:
    - if the report is not a DJ one, then there is not point in checking
      the device_id
    - the receiver (index 0) can also receive some notifications which
      can be safely ignored given the current implementation
    
    Move out the test regarding the report_id and also discards
    printing errors when the receiver got notified.
    
    Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36
    
    Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    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 ae81c27a53af5310f1fe47e9252146d79ab3157d
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Aug 27 09:12:24 2014 +0200

    HID: magicmouse: sanity check report size in raw_event() callback
    
    commit c54def7bd64d7c0b6993336abcffb8444795bf38 upstream.
    
    The report passed to us from transport driver could potentially be
    arbitrarily large, therefore we better sanity-check it so that
    magicmouse_emit_touch() gets only valid values of raw_id.
    
    Reported-by: Steven Vittitoe <scvitti@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2dffad6784f0c5f10727a20a333db11eef0b572a
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Aug 27 09:13:15 2014 +0200

    HID: picolcd: sanity check report size in raw_event() callback
    
    commit 844817e47eef14141cf59b8d5ac08dd11c0a9189 upstream.
    
    The report passed to us from transport driver could potentially be
    arbitrarily large, therefore we better sanity-check it so that raw_data
    that we hold in picolcd_pending structure are always kept within proper
    bounds.
    
    Reported-by: Steven Vittitoe <scvitti@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5c6bd860f60c1981a24d3f8f5ecd6459fd0b084c
Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date:   Tue Aug 26 20:56:36 2014 +0900

    cfq-iosched: Fix wrong children_weight calculation
    
    commit e15693ef18e13e3e6bffe891fe140f18b8ff6d07 upstream.
    
    cfq_group_service_tree_add() is applying new_weight at the beginning of
    the function via cfq_update_group_weight().
    This actually allows weight to change between adding it to and subtracting
    it from children_weight, and triggers WARN_ON_ONCE() in
    cfq_group_service_tree_del(), or even causes oops by divide error during
    vfr calculation in cfq_group_service_tree_add().
    
    The detailed scenario is as follows:
    1. Create blkio cgroups X and Y as a child of X.
       Set X's weight to 500 and perform some I/O to apply new_weight.
       This X's I/O completes before starting Y's I/O.
    2. Y starts I/O and cfq_group_service_tree_add() is called with Y.
    3. cfq_group_service_tree_add() walks up the tree during children_weight
       calculation and adds parent X's weight (500) to children_weight of root.
       children_weight becomes 500.
    4. Set X's weight to 1000.
    5. X starts I/O and cfq_group_service_tree_add() is called with X.
    6. cfq_group_service_tree_add() applies its new_weight (1000).
    7. I/O of Y completes and cfq_group_service_tree_del() is called with Y.
    8. I/O of X completes and cfq_group_service_tree_del() is called with X.
    9. cfq_group_service_tree_del() subtracts X's weight (1000) from
       children_weight of root. children_weight becomes -500.
       This triggers WARN_ON_ONCE().
    10. Set X's weight to 500.
    11. X starts I/O and cfq_group_service_tree_add() is called with X.
    12. cfq_group_service_tree_add() applies its new_weight (500) and adds it
        to children_weight of root. children_weight becomes 0. Calcularion of
        vfr triggers oops by divide error.
    
    weight should be updated right before adding it to children_weight.
    
    Reported-by: Ruki Sekiya <sekiya.ruki@lab.ntt.co.jp>
    Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b56ae06169d87ef18a790efbc972fbd108ec12b4
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sun Sep 21 22:50:57 2014 +0200

    ALSA: pcm: fix fifo_size frame calculation
    
    commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream.
    
    The calculated frame size was wrong because snd_pcm_format_physical_width()
    actually returns the number of bits, not bytes.
    
    Use snd_pcm_format_size() instead, which not only returns bytes, but also
    simplifies the calculation.
    
    Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling")
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6daa982f4368f01a5586866f7281f75e2304e6e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 11 12:59:21 2014 +0200

    ALSA: hda - Fix invalid pin powermap without jack detection
    
    commit 7a9744cb455e6faa287e148394b4b422a6f3c5c4 upstream.
    
    When a driver is set up without the jack detection explicitly (either
    by passing a model option or via a specific fixup), the pin powermap
    of IDT/STAC codecs is set up wrongly, resulting in the silence
    output.  It's because of a logic failure in stac_init_power_map().
    It tries to avoid creating a callback for the pins that have other
    auto-hp and auto-mic callbacks, but the check is done in a wrong way
    at a wrong time.  The stac_init_power_map() should be called after
    creating other jack detection ctls, and the jack callback should be
    created only for jack-detectable widgets.
    
    This patch fixes the check in stac_init_power_map() and its callee
    at the right place, after snd_hda_gen_build_controls().
    
    Reported-by: Adam Richter <adam_richter2004@yahoo.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 61cb0c75227ea08be8cc296892f0021228186504
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Sep 2 07:21:56 2014 +0200

    ALSA: hda - Fix COEF setups for ALC1150 codec
    
    commit acf08081adb5e8fe0519eb97bb49797ef52614d6 upstream.
    
    ALC1150 codec seems to need the COEF- and PLL-setups just like its
    compatible ALC882 codec.  Some machines (e.g. SunMicro X10SAT) show
    the problem like too low output volumes unless the COEF setup is
    applied.
    
    Reported-and-tested-by: Dana Goyette <danagoyette@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ab14104baeb67b25a4f3c152305398b7a2ed868c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 1 14:26:49 2014 +0200

    ALSA: hda - Fix digital mic on Acer Aspire 3830TG
    
    commit ff50479ad61069f3ee14863225aebe36d598e93e upstream.
    
    Acer Aspire 3830TG with CX20588 codec has a digital built-in mic that
    has the same problem like many others, the inverted signal in stereo.
    Apply the same fixup to this machine, too.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9e5a350be060ccb5634f26f3b3dfa749b4f116f4
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Thu Aug 21 20:55:21 2014 +0200

    ALSA: core: fix buffer overflow in snd_info_get_line()
    
    commit ddc64b278a4dda052390b3de1b551e59acdff105 upstream.
    
    snd_info_get_line() documents that its last parameter must be one
    less than the buffer size, but this API design guarantees that
    (literally) every caller gets it wrong.
    
    Just change this parameter to have its obvious meaning.
    
    Reported-by: Tommi Rantala <tt.rantala@gmail.com>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ac0d0d8e3f5cb7503a269674cddf04a56589fb3c
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 22 14:13:24 2014 +0100

    arm64: ptrace: fix compat hardware watchpoint reporting
    
    commit 27d7ff273c2aad37b28f6ff0cab2cfa35b51e648 upstream.
    
    I'm not sure what I was on when I wrote this, but when iterating over
    the hardware watchpoint array (hbp_watch_array), our index is off by
    ARM_MAX_BRP, so we walk off the end of our thread_struct...
    
    ... except, a dodgy condition in the loop means that it never executes
    at all (bp cannot be NULL).
    
    This patch fixes the code so that we remove the bp check and use the
    correct index for accessing the watchpoint structures.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 531402e06165b02cac3c5f1d5ccb1db665f0b7e0
Author: Josef Bacik <jbacik@fb.com>
Date:   Mon Aug 25 13:59:41 2014 -0400

    trace: Fix epoll hang when we race with new entries
    
    commit 4ce97dbf50245227add17c83d87dc838e7ca79d0 upstream.
    
    Epoll on trace_pipe can sometimes hang in a weird case.  If the ring buffer is
    empty when we set waiters_pending but an event shows up exactly at that moment
    we can miss being woken up by the ring buffers irq work.  Since
    ring_buffer_empty() is inherently racey we will sometimes think that the buffer
    is not empty.  So we don't get woken up and we don't think there are any events
    even though there were some ready when we added the watch, which makes us hang.
    This patch fixes this by making sure that we are actually on the wait list
    before we set waiters_pending, and add a memory barrier to make sure
    ring_buffer_empty() is going to be correct.
    
    Link: http://lkml.kernel.org/p/1408989581-23727-1-git-send-email-jbacik@fb.com
    
    Cc: Martin Lau <kafai@fb.com>
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 19c365577e5de2b3f671ad2efbe7556e1f5dcc38
Author: Fan Du <fan.du@intel.com>
Date:   Tue Sep 16 17:21:04 2014 +0800

    i2c: ismt: use correct length when copy buffer
    
    commit 979bbf7b7ae75cfc06e09d09eda38009a3bdc4a4 upstream.
    
    In block write mode, when encapsulating dma_buffer, first element is
    'command', the rest is data buffer, so only copy actual data buffer
    starting from block[1] with the size indicating by block[0].
    
    Signed-off-by: Fan Du <fan.du@intel.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit af8d4c48a1e245b8110e329a4cbd14280aa5bc30
Author: Simon Lindgren <simon@aqwary.com>
Date:   Tue Aug 26 21:13:24 2014 +0200

    i2c: at91: Fix a race condition during signal handling in at91_do_twi_xfer.
    
    commit 6721f28a26efd6368497abbdef5dcfc59608d899 upstream.
    
    There is a race condition in at91_do_twi_xfer when signals arrive.
    If a signal is recieved while waiting for a transfer to complete
    wait_for_completion_interruptible_timeout() will return -ERESTARTSYS.
    This is not handled correctly resulting in interrupts still being
    enabled and a transfer being in flight when we return.
    
    Symptoms include a range of oopses and bus lockups. Oopses can happen
    when the transfer completes because the interrupt handler will corrupt
    the stack. If a new transfer is started before the interrupt fires
    the controller will start a new transfer in the middle of the old one,
    resulting in confused slaves and a locked bus.
    
    To avoid this, use wait_for_completion_io_timeout instead so that we
    don't have to deal with gracefully shutting down the transfer and
    disabling the interrupts.
    
    Signed-off-by: Simon Lindgren <simon@aqwary.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4c539a1996174a3ec059685fe3d14b4962ff6ca2
Author: Marek Roszko <mark.roszko@gmail.com>
Date:   Wed Aug 20 21:39:41 2014 -0400

    i2c: at91: add bound checking on SMBus block length bytes
    
    commit 75b81f339c6af43f6f4a1b3eabe0603321dade65 upstream.
    
    The driver was not bound checking the received length byte to ensure it was within the
    the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows
    whenever an invalid length byte was received.
    It also failed to ensure the length byte was not zero. If it received zero, it would end up
    in an infinite loop as the at91_twi_read_next_byte function returned immediately without
    allowing RHR to be read to clear the RXRDY interrupt.
    
    Tested agaisnt a SMBus compliant battery.
    
    Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 32974f960cb8a432888c35577c363da0d6a19a4d
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Mon Sep 1 22:28:13 2014 +0800

    i2c: mv64xxx: continue probe when clock-frequency is missing
    
    commit 0ce4bc1dbdd911ae1763e2d4ff36bd1b214a59f7 upstream.
    
    The "clock-frequency" DT property is listed as optional, However,
    the current code stores the return value of of_property_read_u32 in
    the return code of mv64xxx_of_config, but then forgets to clear it
    after setting the default value of "clock-frequency". It is then
    passed out to the main probe function, resulting in a probe failure
    when "clock-frequency" is missing.
    
    This patch checks and then throws away the return value of
    of_property_read_u32, instead of storing it and having to clear it
    afterwards.
    
    This issue was discovered after the property was removed from all
    sunxi DTs.
    
    Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0a6afabb7d57d5dff388e0a8e7022028056a9485
Author: Dave Martin <dave.martin@linaro.org>
Date:   Mon Nov 25 14:54:47 2013 +0100

    ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel
    
    commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 upstream.
    
    Copying a function with memcpy() and then trying to execute the
    result isn't trivially portable to Thumb.
    
    This patch modifies the kexec soft restart code to copy its
    assembler trampoline relocate_new_kernel() using fncpy() instead,
    so that relocate_new_kernel can be in the same ISA as the rest of
    the kernel without problems.
    
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
    Tested-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f68c88364ed46e15850cfaf7b57ce5aedfe4f696
Author: Julian Anastasov <ja@ssi.bg>
Date:   Fri Aug 22 17:53:41 2014 +0300

    ipvs: fix ipv6 hook registration for local replies
    
    commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream.
    
    commit fc604767613b6d2036cdc35b660bc39451040a47
    ("ipvs: changes for local real server") from 2.6.37
    introduced DNAT support to local real server but the
    IPv6 LOCAL_OUT handler ip_vs_local_reply6() is
    registered incorrectly as IPv4 hook causing any outgoing
    IPv4 traffic to be dropped depending on the IP header values.
    
    Chris tracked down the problem to CONFIG_IP_VS_IPV6=y
    Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768
    
    Reported-by: Chris J Arges <chris.j.arges@canonical.com>
    Tested-by: Chris J Arges <chris.j.arges@canonical.com>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1369e8861da3528bdf4923b706ffd406119ea240
Author: Alex Gartrell <agartrell@fb.com>
Date:   Wed Jul 16 15:57:34 2014 -0700

    ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding
    
    commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream.
    
    Previously, only the four high bits of the tclass were maintained in the
    ipv6 case.  This matches the behavior of ipv4, though whether or not we
    should reflect ECN bits may be up for debate.
    
    Signed-off-by: Alex Gartrell <agartrell@fb.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 46b9739460f9880de0e9eae26494d077538b197b
Author: Julian Anastasov <ja@ssi.bg>
Date:   Thu Jul 10 09:24:01 2014 +0300

    ipvs: avoid netns exit crash on ip_vs_conn_drop_conntrack
    
    commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream.
    
    commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack")
    added second ip_vs_conn_drop_conntrack call instead of just adding
    the needed check. As result, the first call still can cause
    crash on netns exit. Remove it.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 60f09acea19cc0638f87d1beded9a48287a43466
Author: Michal Hocko <mhocko@suse.cz>
Date:   Thu Jan 23 15:53:15 2014 -0800

    mm: new_vma_page() cannot see NULL vma for hugetlb pages
    
    commit cc81717ed3bc6d4f3738d13a1e097437caada0e9 upstream.
    
    Commit 11c731e81bb0 ("mm/mempolicy: fix !vma in new_vma_page()") has
    removed BUG_ON(!vma) from new_vma_page which is partially correct
    because page_address_in_vma will return EFAULT for non-linear mappings
    and at least shared shmem might be mapped this way.
    
    The patch also tried to prevent NULL ptr for hugetlb pages which is not
    correct AFAICS because hugetlb pages cannot be mapped as VM_NONLINEAR
    and other conditions in page_address_in_vma seem to be legit and catch
    real bugs.
    
    This patch restores BUG_ON for PageHuge to catch potential issues when
    the to-be-migrated page is not setup properly.
    
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: Bob Liu <bob.liu@oracle.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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 7d97f39bc813aa9f11fe03d602885f81de07007c
Author: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Date:   Wed Dec 18 17:08:56 2013 -0800

    mm/mempolicy: fix !vma in new_vma_page()
    
    commit 11c731e81bb0d8d2e835447a2dd645b34bb74706 upstream.
    
    BUG_ON(!vma) assumption is introduced by commit 0bf598d863e3 ("mbind:
    add BUG_ON(!vma) in new_vma_page()"), however, even if
    
        address = __vma_address(page, vma);
    
    and
    
        vma->start < address < vma->end
    
    page_address_in_vma() may still return -EFAULT because of many other
    conditions in it.  As a result the while loop in new_vma_page() may end
    with vma=NULL.
    
    This patch revert the commit and also fix the potential dereference NULL
    pointer reported by Dan.
    
       http://marc.info/?l=linux-mm&m=137689530323257&w=2
    
      kernel BUG at mm/mempolicy.c:1204!
      invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU: 3 PID: 7056 Comm: trinity-child3 Not tainted 3.13.0-rc3+ #2
      task: ffff8801ca5295d0 ti: ffff88005ab20000 task.ti: ffff88005ab20000
      RIP: new_vma_page+0x70/0x90
      RSP: 0000:ffff88005ab21db0  EFLAGS: 00010246
      RAX: fffffffffffffff2 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000008040075 RSI: ffff8801c3d74600 RDI: ffffea00079a8b80
      RBP: ffff88005ab21dc8 R08: 0000000000000004 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: fffffffffffffff2
      R13: ffffea00079a8b80 R14: 0000000000400000 R15: 0000000000400000
    
      FS:  00007ff49c6f4740(0000) GS:ffff880244e00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ff49c68f994 CR3: 000000005a205000 CR4: 00000000001407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
       ffffea00079a8b80 ffffea00079a8bc0 ffffea00079a8ba0 ffff88005ab21e50
       ffffffff811adc7a 0000000000000000 ffff8801ca5295d0 0000000464e224f8
       0000000000000000 0000000000000002 0000000000000000 ffff88020ce75c00
      Call Trace:
        migrate_pages+0x12a/0x850
        SYSC_mbind+0x513/0x6a0
        SyS_mbind+0xe/0x10
        ia32_do_call+0x13/0x13
      Code: 85 c0 75 2f 4c 89 e1 48 89 da 31 f6 bf da 00 02 00 65 44 8b 04 25 08 f7 1c 00 e8 ec fd ff ff 5b 41 5c 41 5d 5d c3 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 4c 89 e6 48 89 df ba 01 00 00 00 e8 48
      RIP  [<ffffffff8119f200>] new_vma_page+0x70/0x90
       RSP <ffff88005ab21db0>
    
    Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Bob Liu <bob.liu@oracle.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>