commit e08e9457eeba01608645e398c7e69b2fb40e31a9
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Apr 2 00:59:03 2014 +0100

    Linux 3.2.56

commit f41b3d0bf8050e97ec8118537547213e85ce093c
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 11 14:22:19 2014 -0600

    PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
    
    commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream.
    
    Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
    them disabled"), pciehp surprise removal stopped working.
    
    This happens because pci_reenable_device() on the hotplug bridge (used in
    the pciehp_configure_device() path) clears the Interrupt Disable bit, which
    apparently breaks the bridge's MSI hotplug event reporting.
    
    Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
    which is used by both pci_enable_device() and pci_reenable_device().  But
    we use pci_reenable_device() after the driver may have enabled MSI or
    MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
    
    This patch clears Interrupt Disable only when MSI/MSI-X has not been
    enabled.
    
    Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
    Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dcd8e204d28377b29539f7e97bf91fc7ef50ab17
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Aug 16 22:06:55 2012 +0200

    intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.
    
    commit 3735d524da64b70b41c764359da36f88aded3610 upstream.
    
    If the machine is booted without any cpu_idle driver set
    (b/c disable_cpuidle() has been called) we should follow
    other users of cpu_idle API and check the return value
    for NULL before using it.
    
    Reported-and-tested-by: Mark van Dijk <mark@internecto.net>
    Suggested-by: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c7160985f53fe845eb5e882a492196a844962650
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Mon Mar 3 17:23:04 2014 +0100

    net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable
    
    [ Upstream commit ec0223ec48a90cb605244b45f7c62de856403729 ]
    
    RFC4895 introduced AUTH chunks for SCTP; during the SCTP
    handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
    being optional though):
    
      ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
      <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
      -------------------- COOKIE-ECHO -------------------->
      <-------------------- COOKIE-ACK ---------------------
    
    A special case is when an endpoint requires COOKIE-ECHO
    chunks to be authenticated:
    
      ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
      <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
      ------------------ AUTH; COOKIE-ECHO ---------------->
      <-------------------- COOKIE-ACK ---------------------
    
    RFC4895, section 6.3. Receiving Authenticated Chunks says:
    
      The receiver MUST use the HMAC algorithm indicated in
      the HMAC Identifier field. If this algorithm was not
      specified by the receiver in the HMAC-ALGO parameter in
      the INIT or INIT-ACK chunk during association setup, the
      AUTH chunk and all the chunks after it MUST be discarded
      and an ERROR chunk SHOULD be sent with the error cause
      defined in Section 4.1. [...] If no endpoint pair shared
      key has been configured for that Shared Key Identifier,
      all authenticated chunks MUST be silently discarded. [...]
    
      When an endpoint requires COOKIE-ECHO chunks to be
      authenticated, some special procedures have to be followed
      because the reception of a COOKIE-ECHO chunk might result
      in the creation of an SCTP association. If a packet arrives
      containing an AUTH chunk as a first chunk, a COOKIE-ECHO
      chunk as the second chunk, and possibly more chunks after
      them, and the receiver does not have an STCB for that
      packet, then authentication is based on the contents of
      the COOKIE-ECHO chunk. In this situation, the receiver MUST
      authenticate the chunks in the packet by using the RANDOM
      parameters, CHUNKS parameters and HMAC_ALGO parameters
      obtained from the COOKIE-ECHO chunk, and possibly a local
      shared secret as inputs to the authentication procedure
      specified in Section 6.3. If authentication fails, then
      the packet is discarded. If the authentication is successful,
      the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
      MUST be processed. If the receiver has an STCB, it MUST
      process the AUTH chunk as described above using the STCB
      from the existing association to authenticate the
      COOKIE-ECHO chunk and all the chunks after it. [...]
    
    Commit bbd0d59809f9 introduced the possibility to receive
    and verification of AUTH chunk, including the edge case for
    authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
    the function sctp_sf_do_5_1D_ce() handles processing,
    unpacks and creates a new association if it passed sanity
    checks and also tests for authentication chunks being
    present. After a new association has been processed, it
    invokes sctp_process_init() on the new association and
    walks through the parameter list it received from the INIT
    chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO
    and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
    meta data (peer_random, peer_hmacs, peer_chunks) in case
    sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
    SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set,
    peer_random != NULL and peer_hmacs != NULL the peer is to be
    assumed asoc->peer.auth_capable=1, in any other case
    asoc->peer.auth_capable=0.
    
    Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
    available, we set up a fake auth chunk and pass that on to
    sctp_sf_authenticate(), which at latest in
    sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
    at position 0..0008 when setting up the crypto key in
    crypto_hash_setkey() by using asoc->asoc_shared_key that is
    NULL as condition key_id == asoc->active_key_id is true if
    the AUTH chunk was injected correctly from remote. This
    happens no matter what net.sctp.auth_enable sysctl says.
    
    The fix is to check for net->sctp.auth_enable and for
    asoc->peer.auth_capable before doing any operations like
    sctp_sf_authenticate() as no key is activated in
    sctp_auth_asoc_init_active_key() for each case.
    
    Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
    passed from the INIT chunk was not used in the AUTH chunk, we
    SHOULD send an error; however in this case it would be better
    to just silently discard such a maliciously prepared handshake
    as we didn't even receive a parameter at all. Also, as our
    endpoint has no shared key configured, section 6.3 says that
    MUST silently discard, which we are doing from now onwards.
    
    Before calling sctp_sf_pdiscard(), we need not only to free
    the association, but also the chunk->auth_chunk skb, as
    commit bbd0d59809f9 created a skb clone in that case.
    
    I have tested this locally by using netfilter's nfqueue and
    re-injecting packets into the local stack after maliciously
    modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
    and the SCTP packet containing the COOKIE_ECHO (injecting
    AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.
    
    Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Vlad Yasevich <yasevich@gmail.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 608532c1a1ad84bfdb1d2ed1b99d298358e285a0
Author: Michael Chan <mchan@broadcom.com>
Date:   Fri Feb 28 15:05:10 2014 -0800

    tg3: Don't check undefined error bits in RXBD
    
    [ Upstream commit d7b95315cc7f441418845a165ee56df723941487 ]
    
    Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
    a customer reported issue of randomly dropping packets on the 5719.
    
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ddc63f2b28118d6e05d79b6899705edfdf5cacd8
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri Feb 21 13:08:04 2014 +0800

    virtio-net: alloc big buffers also when guest can receive UFO
    
    [ Upstream commit 0e7ede80d929ff0f830c44a543daa1acd590c749 ]
    
    We should alloc big buffers also when guest can receive UFO
    packets to let the big packets fit into guest rx buffer.
    
    Fixes 5c5167515d80f78f6bb538492c423adcae31ad65
    (virtio-net: Allow UFO feature to be set and advertised.)
    
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Sridhar Samudrala <sri@us.ibm.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc9664f18ab68a3fabafe6836d6d398c0f3b61de
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sat Jul 27 03:53:54 2013 -0700

    jiffies: Avoid undefined behavior from signed overflow
    
    commit 5a581b367b5df0531265311fc681c2abd377e5e6 upstream.
    
    According to the C standard 3.4.3p3, overflow of a signed integer results
    in undefined behavior.  This commit therefore changes the definitions
    of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
    to avoid this undefined behavior.  The trick is that the subtraction
    is done using unsigned arithmetic, which according to 6.2.5p9 cannot
    overflow because it is defined as modulo arithmetic.  This has the added
    (though admittedly quite small) benefit of shortening four lines of code
    by four characters each.
    
    Note that the C standard considers the cast from unsigned to
    signed to be implementation-defined, see 6.3.1.3p3.  However, on a
    two's-complement system, an implementation that defines anything other
    than a reinterpretation of the bits is free to come to me, and I will be
    happy to act as a witness for its being committed to an insane asylum.
    (Although I have nothing against saturating arithmetic or signals in some
    cases, these things really should not be the default when compiling an
    operating-system kernel.)
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Kevin Easton <kevin@guarana.org>
    [ paulmck: Included time_after64() and time_after_eq64(), as suggested
      by Eric Dumazet, also fixed commit message.]
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 54a19ec5469fcaf9a91cffb2a81eae2d13f46726
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Wed Mar 5 22:16:17 2014 +0100

    ALSA: oxygen: Xonar DG(X): modify DAC routing
    
    commit 1f91ecc14deea9461aca93273d78871ec4d98fcd upstream.
    
    When selecting the audio output destinations (headphones, FP headphones,
    multichannel output), unnecessary I2S channels are digitally muted to
    avoid invalid signal levels on the other outputs.
    
    Signed-off-by: Roman Volkov <v1ron@mail.ru>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 935e68c6e197e3c2ed906fba935246a81f0b30d9
Author: Roman Volkov <v1ron@mail.ru>
Date:   Fri Jan 24 16:18:14 2014 +0400

    ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2
    
    commit 3dd77654fb1d7f68b9739f3039bad8dbbc0739f8 upstream.
    
    Actually CS4245 connected to the I2S channel 1 for
    capture, not channel 2. Otherwise capturing and
    playback does not work for CS4245.
    
    Signed-off-by: Roman Volkov <v1ron@mail.ru>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd615645d48059174b3900a828c9c7a80c749427
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 18:00:59 2013 +0200

    saa7134: Fix unlocked snd_pcm_stop() call
    
    commit e6355ad7b1c6f70e2f48ae159f5658b441ccff95 upstream.
    
    snd_pcm_stop() must be called in the PCM substream lock context.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [wml: Backported to 3.4: Adjust filename]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9924c0fa968bb6104a99b7b7961a6c188fed9b31
Author: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
Date:   Wed Oct 24 11:45:46 2012 +0200

    cifs: set MAY_SIGN when sec=krb5
    
    commit 0b7bc84000d71f3647ca33ab1bf5bd928535c846 upstream.
    
    Setting this secFlg allows usage of dfs where some servers require
    signing and others don't.
    
    Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    [Joseph Salisbury: This backport was done so including mainline commit
    8830d7e07a5e38bc47650a7554b7c1cfd49902bf is not needed.]
    BugLink: http://bugs.launchpad.net/bugs/1285723
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ffbd2b62c349e1541513883b25bcecc2fa238e60
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Mon Feb 17 12:11:11 2014 +0100

    net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
    
    [ Upstream commit ffd5939381c609056b33b7585fb05a77b4c695f3 ]
    
    SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
    emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
    'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
    sizeof(param) check will always fail in kernel as the structure in
    64bit kernel space is 4bytes larger than for user binaries compiled
    in 32bit mode. Thus, applications making use of sctp_connectx() won't
    be able to run under such circumstances.
    
    Introduce a compat interface in the kernel to deal with such
    situations by using a 'struct compat_sctp_getaddrs_old' structure
    where user data is copied into it, and then sucessively transformed
    into a 'struct sctp_getaddrs_old' structure with the help of
    compat_ptr(). That fixes sctp_connectx() abi without any changes
    needed in user space, and lets the SCTP test suite pass when compiled
    in 32bit and run on 64bit kernels.
    
    Fixes: f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 22bff3616cf35c5e19da9169f560e4336020899c
Author: Jiri Bohac <jiri@boha.cz>
Date:   Fri Feb 14 18:13:50 2014 +0100

    bonding: 802.3ad: make aggregator_identifier bond-private
    
    [ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]
    
    aggregator_identifier is used to assign unique aggregator identifiers
    to aggregators of a bond during device enslaving.
    
    aggregator_identifier is currently a global variable that is zeroed in
    bond_3ad_initialize().
    
    This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
    
    create bond0
    change bond0 mode to 802.3ad
    enslave eth0 to bond0 		//eth0 gets agg id 1
    enslave eth1 to bond0 		//eth1 gets agg id 2
    create bond1
    change bond1 mode to 802.3ad
    enslave eth2 to bond1		//aggregator_identifier is reset to 0
    				//eth2 gets agg id 1
    enslave eth3 to bond0 		//eth3 gets agg id 2
    
    Fix this by making aggregator_identifier private to the bond.
    
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-by: Veaceslav Falico <vfalico@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7bf67232f8f765c1a927431b143717ec7fdc8d1c
Author: Emil Goode <emilgoode@gmail.com>
Date:   Thu Feb 13 17:50:19 2014 +0100

    usbnet: remove generic hard_header_len check
    
    [ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]
    
    This patch removes a generic hard_header_len check from the usbnet
    module that is causing dropped packages under certain circumstances
    for devices that send rx packets that cross urb boundaries.
    
    One example is the AX88772B which occasionally send rx packets that
    cross urb boundaries where the remaining partial packet is sent with
    no hardware header. When the buffer with a partial packet is of less
    number of octets than the value of hard_header_len the buffer is
    discarded by the usbnet module.
    
    With AX88772B this can be reproduced by using ping with a packet
    size between 1965-1976.
    
    The bug has been reported here:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=29082
    
    This patch introduces the following changes:
    - Removes the generic hard_header_len check in the rx_complete
      function in the usbnet module.
    - Introduces a ETH_HLEN check for skbs that are not cloned from
      within a rx_fixup callback.
    - For safety a hard_header_len check is added to each rx_fixup
      callback function that could be affected by this change.
      These extra checks could possibly be removed by someone
      who has the hardware to test.
    - Removes a call to dev_kfree_skb_any() and instead utilizes the
      dev->done list to queue skbs for cleanup.
    
    The changes place full responsibility on the rx_fixup callback
    functions that clone skbs to only pass valid skbs to the
    usbnet_skb_return function.
    
    Signed-off-by: Emil Goode <emilgoode@gmail.com>
    Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9a46001eeb563bf2f11c13568b2e255915e028cd
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Thu Feb 6 14:13:05 2014 -0800

    tg3: Fix deadlock in tg3_change_mtu()
    
    [ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ]
    
    Quoting David Vrabel -
    "5780 cards cannot have jumbo frames and TSO enabled together.  When
    jumbo frames are enabled by setting the MTU, the TSO feature must be
    cleared.  This is done indirectly by calling netdev_update_features()
    which will call tg3_fix_features() to actually clear the flags.
    
    netdev_update_features() will also trigger a new netlink message for the
    feature change event which will result in a call to tg3_get_stats64()
    which deadlocks on the tg3 lock."
    
    tg3_set_mtu() does not need to be under the tg3 lock since converting
    the flags to use set_bit(). Move it out to after tg3_netif_stop().
    
    Reported-by: David Vrabel <david.vrabel@citrix.com>
    Tested-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c62fcd97e7f12e8f617db30eda0946997baeda4
Author: Maciej Żenczykowski <maze@google.com>
Date:   Fri Feb 7 16:23:48 2014 -0800

    net: fix 'ip rule' iif/oif device rename
    
    [ Upstream commit 946c032e5a53992ea45e062ecb08670ba39b99e3 ]
    
    ip rules with iif/oif references do not update:
    (detach/attach) across interface renames.
    
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    CC: Willem de Bruijn <willemb@google.com>
    CC: Eric Dumazet <edumazet@google.com>
    CC: Chris Davis <chrismd@google.com>
    CC: Carlo Contavalli <ccontavalli@google.com>
    
    Google-Bug-Id: 12936021
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8db5f989887fe1d37757d02caf47cbc6cc49199
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon Oct 15 21:35:59 2012 -0700

    printk: Fix scheduling-while-atomic problem in console_cpu_notify()
    
    commit 85eae82a0855d49852b87deac8653e4ebc8b291f upstream.
    
    The console_cpu_notify() function runs with interrupts disabled in the
    CPU_DYING case.  It therefore cannot block, for example, as will happen
    when it calls console_lock().  Therefore, remove the CPU_DYING leg of
    the switch statement to avoid this problem.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7f4d7e8fe42d3a34994055355694236f489c874f
Author: Colin Cross <ccross@android.com>
Date:   Mon Feb 10 13:16:29 2014 -0800

    timekeeping: fix 32-bit overflow in get_monotonic_boottime
    
    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c
    
    get_monotonic_boottime adds three nanonsecond values stored
    in longs, followed by an s64.  If the long values are all
    close to 1e9 the first three additions can overflow and
    become negative when added to the s64.  Cast the first
    value to s64 so that all additions are 64 bit.
    
    Signed-off-by: Colin Cross <ccross@android.com>
    [jstultz: Fished this out of the AOSP commong.git tree. This was
    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5162fef0ca711d3d467b6cf181219e43100d7122
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue Feb 11 14:50:01 2014 -0500

    ftrace: Have function graph only trace based on global_ops filters
    
    commit 23a8e8441a0a74dd612edf81dc89d1600bc0a3d1 upstream.
    
    Doing some different tests, I discovered that function graph tracing, when
    filtered via the set_ftrace_filter and set_ftrace_notrace files, does
    not always keep with them if another function ftrace_ops is registered
    to trace functions.
    
    The reason is that function graph just happens to trace all functions
    that the function tracer enables. When there was only one user of
    function tracing, the function graph tracer did not need to worry about
    being called by functions that it did not want to trace. But now that there
    are other users, this becomes a problem.
    
    For example, one just needs to do the following:
    
     # cd /sys/kernel/debug/tracing
     # echo schedule > set_ftrace_filter
     # echo function_graph > current_tracer
     # cat trace
    [..]
     0)               |  schedule() {
     ------------------------------------------
     0)    <idle>-0    =>   rcu_pre-7
     ------------------------------------------
    
     0) ! 2980.314 us |  }
     0)               |  schedule() {
     ------------------------------------------
     0)   rcu_pre-7    =>    <idle>-0
     ------------------------------------------
    
     0) + 20.701 us   |  }
    
     # echo 1 > /proc/sys/kernel/stack_tracer_enabled
     # cat trace
    [..]
     1) + 20.825 us   |      }
     1) + 21.651 us   |    }
     1) + 30.924 us   |  } /* SyS_ioctl */
     1)               |  do_page_fault() {
     1)               |    __do_page_fault() {
     1)   0.274 us    |      down_read_trylock();
     1)   0.098 us    |      find_vma();
     1)               |      handle_mm_fault() {
     1)               |        _raw_spin_lock() {
     1)   0.102 us    |          preempt_count_add();
     1)   0.097 us    |          do_raw_spin_lock();
     1)   2.173 us    |        }
     1)               |        do_wp_page() {
     1)   0.079 us    |          vm_normal_page();
     1)   0.086 us    |          reuse_swap_page();
     1)   0.076 us    |          page_move_anon_rmap();
     1)               |          unlock_page() {
     1)   0.082 us    |            page_waitqueue();
     1)   0.086 us    |            __wake_up_bit();
     1)   1.801 us    |          }
     1)   0.075 us    |          ptep_set_access_flags();
     1)               |          _raw_spin_unlock() {
     1)   0.098 us    |            do_raw_spin_unlock();
     1)   0.105 us    |            preempt_count_sub();
     1)   1.884 us    |          }
     1)   9.149 us    |        }
     1) + 13.083 us   |      }
     1)   0.146 us    |      up_read();
    
    When the stack tracer was enabled, it enabled all functions to be traced, which
    now the function graph tracer also traces. This is a side effect that should
    not occur.
    
    To fix this a test is added when the function tracing is changed, as well as when
    the graph tracer is enabled, to see if anything other than the ftrace global_ops
    function tracer is enabled. If so, then the graph tracer calls a test trampoline
    that will look at the function that is being traced and compare it with the
    filters defined by the global_ops.
    
    As an optimization, if there's no other function tracers registered, or if
    the only registered function tracers also use the global ops, the function
    graph infrastructure will call the registered function graph callback directly
    and not go through the test trampoline.
    
    Fixes: d2d45c7a03a2 "tracing: Have stack_tracer use a separate list of functions"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b89ff066efab68d53a3a060b2c7d9089f8afa8ea
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat May 18 02:38:52 2013 -0400

    hpfs: deadlock and race in directory lseek()
    
    commit 31abdab9c11bb1694ecd1476a7edbe8e964d94ac upstream.
    
    For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
    in hpfs_dir_lseek() - there's a lot of methods that grab the former with
    the caller already holding the latter, so it must take i_mutex first.
    
    For another, locking the damn thing, carefully validating the offset,
    then dropping locks and assigning the offset is obviously racy.
    
    Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
    won't modify the sucker on B-tree surgeries.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 578d1903dcfd8911534aa602ea8c104c383fadda
Author: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Date:   Wed Jan 29 00:10:44 2014 +0100

    hpfs: remember free space
    
    commit 2cbe5c76fc5e38e9af4b709593146e4b8272b69e upstream.
    
    Previously, hpfs scanned all bitmaps each time the user asked for free
    space using statfs.  This patch changes it so that hpfs scans the
    bitmaps only once, remembes the free space and on next invocation of
    statfs it returns the value instantly.
    
    New versions of wine are hammering on the statfs syscall very heavily,
    making some games unplayable when they're stored on hpfs, with load
    times in minutes.
    
    This should be backported to the stable kernels because it fixes
    user-visible problem (excessive level load times in wine).
    
    Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [ kamal: backport to 3.8 (no hpfs_prefetch_bitmap) ]
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b41f1572b428032a7dedc8296250236dbc0229a
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Nov 22 16:47:26 2013 +0100

    TTY: pmac_zilog, check existence of ports in pmz_console_init()
    
    commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.
    
    When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
    on the kernel command line, it crashes with:
    
    Unable to handle kernel NULL pointer dereference at virtual address   (null)
    Oops: 00000000
    PC: [<0013ad28>] __pmz_startup+0x32/0x2a0
    ...
    Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4
    
    The normal tty driver doesn't crash, because init_pmz() checks
    pmz_ports_count again after calling pmz_probe().
    
    In the serial console initialization path, pmz_console_init() doesn't do
    this, causing the driver to crash later.
    
    Add a check for pmz_ports_count to fix this.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Finn Thain <fthain@telegraphics.com.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 358c10d5ce93cf7cf3ae6cd66e2e533d680591d5
Author: Jianguo Wu <wujianguo@huawei.com>
Date:   Wed Dec 18 17:08:59 2013 -0800

    mm/hugetlb: check for pte NULL pointer in __page_check_address()
    
    commit 98398c32f6687ee1e1f3ae084effb4b75adb0747 upstream.
    
    In __page_check_address(), if address's pud is not present,
    huge_pte_offset() will return NULL, we should check the return value.
    
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: qiuxishi <qiuxishi@huawei.com>
    Cc: Hanjun Guo <guohanjun@huawei.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c725cf148008d81eac7fe4bebff7367ae2aa0aa2
Author: Helge Deller <deller@gmx.de>
Date:   Mon Dec 2 19:59:31 2013 +0100

    nfs: fix do_div() warning by instead using sector_div()
    
    commit 3873d064b8538686bbbd4b858dc8a07db1f7f43a upstream.
    
    When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like
    shown below.  Fix this warning by instead using sector_div() which is provided
    by the kernel.h header file.
    
    fs/nfs/blocklayout/extents.c: In function ‘normalize’:
    include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
    fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’
    nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default]
    fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default]
    include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’
    extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41c48b9746b11a8b6fcb1b534f75fd92428c9465
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Aug 20 11:50:19 2013 +0100

    staging: comedi: pcmuio: fix possible NULL deref on detach
    
    commit 2fd2bdfccae61efe18f6b92b6a45fbf936d75b48 upstream.
    
    pcmuio_detach() is called by the comedi core even if pcmuio_attach()
    returned an error, so `dev->private` might be `NULL`.  Check for that
    before dereferencing it.
    
    Also, as pointed out by Dan Carpenter, there is no need to check the
    pointer passed to `kfree()` is non-NULL, so remove that check.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit eafb3d2ee0052bf3f38ff01f4f1699ad0db20459
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Thu Dec 12 11:32:19 2013 +0000

    staging: comedi: ssv_dnp: correct insn_bits result
    
    [Part of commit f6b316bcd8c421acd6fa5a6e18b4c846ecb9d965 upstream.
    Split from original patch subject: "staging: comedi: ssv_dnp: use
    comedi_dio_update_state()"]
    
    Also, fix a bug where the state of the channels is returned in data[0].
    The comedi core expects it to be returned in data[1].
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b10349aded21e5cab89ab99cbc2aa90d00314ee6
Author: Daniel J Blueman <daniel@numascale.com>
Date:   Thu Mar 13 19:43:01 2014 +0800

    x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
    
    commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream.
    
    For systems with multiple servers and routed fabric, all
    northbridges get assigned to the first server. Fix this by also
    using the node reported from the PCI bus. For single-fabric
    systems, the northbriges are on PCI bus 0 by definition, which
    are on NUMA node 0 by definition, so this is invarient on most
    systems.
    
    Tested on fam10h and fam15h single and multi-fabric systems and
    candidate for stable.
    
    Signed-off-by: Daniel J Blueman <daniel@numascale.com>
    Acked-by: Steffen Persvold <sp@numascale.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd840143ae1bd82d1fe37914956198b24235c3a9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 13 10:44:34 2014 +0100

    vmxnet3: fix building without CONFIG_PCI_MSI
    
    commit 0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream.
    
    Since commit d25f06ea466e "vmxnet3: fix netpoll race condition",
    the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
    because it unconditionally references the vmxnet3_msix_rx()
    function.
    
    To fix this, use the same #ifdef in the caller that exists around
    the function definition.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
    Cc: "VMware, Inc." <pv-drivers@vmware.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c885403b60fe0fadb3d11319007827617e5bdb0
Author: Radim Krčmář <rkrcmar@redhat.com>
Date:   Tue Mar 11 19:11:18 2014 +0100

    KVM: SVM: fix cr8 intercept window
    
    commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream.
    
    We always disable cr8 intercept in its handler, but only re-enable it
    if handling KVM_REQ_EVENT, so there can be a window where we do not
    intercept cr8 writes, which allows an interrupt to disrupt a higher
    priority task.
    
    Fix this by disabling intercepts in the same function that re-enables
    them when needed. This fixes BSOD in Windows 2008.
    
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1b1228fd19c63d85e218df806a79c634df9053fb
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Mon Mar 10 06:55:55 2014 -0400

    vmxnet3: fix netpoll race condition
    
    commit d25f06ea466ea521b563b76661180b4e44714ae6 upstream.
    
    vmxnet3's netpoll driver is incorrectly coded.  It directly calls
    vmxnet3_do_poll, which is the driver internal napi poll routine.  As the netpoll
    controller method doesn't block real napi polls in any way, there is a potential
    for race conditions in which the netpoll controller method and the napi poll
    method run concurrently.  The result is data corruption causing panics such as this
    one recently observed:
    PID: 1371   TASK: ffff88023762caa0  CPU: 1   COMMAND: "rs:main Q:Reg"
     #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b
     #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92
     #2 [ffff88023abd58b0] oops_end at ffffffff8152b570
     #3 [ffff88023abd58e0] die at ffffffff81010e0b
     #4 [ffff88023abd5910] do_trap at ffffffff8152add4
     #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95
     #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b
        [exception RIP: vmxnet3_rq_rx_complete+1968]
        RIP: ffffffffa00f1e80  RSP: ffff88023abd5ac8  RFLAGS: 00010086
        RAX: 0000000000000000  RBX: ffff88023b5dcee0  RCX: 00000000000000c0
        RDX: 0000000000000000  RSI: 00000000000005f2  RDI: ffff88023b5dcee0
        RBP: ffff88023abd5b48   R8: 0000000000000000   R9: ffff88023a3b6048
        R10: 0000000000000000  R11: 0000000000000002  R12: ffff8802398d4cd8
        R13: ffff88023af35140  R14: ffff88023b60c890  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3]
     #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3]
     #9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7
    
    The fix is to do as other drivers do, and have the poll controller call the top
    half interrupt handler, which schedules a napi poll properly to recieve frames
    
    Tested by myself, successfully.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: Shreyas Bhatewara <sbhatewara@vmware.com>
    CC: "VMware, Inc." <pv-drivers@vmware.com>
    CC: "David S. Miller" <davem@davemloft.net>
    Reviewed-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb183963fa094a6973797eb7b4bf7106da565146
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Feb 10 15:18:55 2014 -0500

    ocfs2 syncs the wrong range...
    
    commit 1b56e98990bcdbb20b9fab163654b9315bf158e8 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8cba29a4a1a0f968c47c8205b7fe40ae9af9c18f
Author: Giridhar Malavali <giridhar.malavali@qlogic.com>
Date:   Wed Feb 26 04:15:12 2014 -0500

    qla2xxx: Poll during initialization for ISP25xx and ISP83xx
    
    commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.
    
    Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - QLA83XX was not included]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13554d2017c77801352e6122e24a7da0517edb64
Author: Lukasz Dorau <lukasz.dorau@intel.com>
Date:   Thu Feb 6 12:23:20 2014 -0800

    isci: correct erroneous for_each_isci_host macro
    
    commit c59053a23d586675c25d789a7494adfdc02fba57 upstream.
    
    In the first place, the loop 'for' in the macro 'for_each_isci_host'
    (drivers/scsi/isci/host.h:314) is incorrect, because it accesses
    the 3rd element of 2 element array. After the 2nd iteration it executes
    the instruction:
            ihost = to_pci_info(pdev)->hosts[2]
    (while the size of the 'hosts' array equals 2) and reads an
    out of range element.
    
    In the second place, this loop is incorrectly optimized by GCC v4.8
    (see http://marc.info/?l=linux-kernel&m=138998871911336&w=2).
    As a result, on platforms with two SCU controllers,
    the loop is executed more times than it can be (for i=0,1 and 2).
    It causes kernel panic during entering the S3 state
    and the following oops after 'rmmod isci':
    
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff8131360b>] __list_add+0x1b/0xc0
    Oops: 0000 [#1] SMP
    RIP: 0010:[<ffffffff8131360b>]  [<ffffffff8131360b>] __list_add+0x1b/0xc0
    Call Trace:
      [<ffffffff81661b84>] __mutex_lock_slowpath+0x114/0x1b0
      [<ffffffff81661c3f>] mutex_lock+0x1f/0x30
      [<ffffffffa03e97cb>] sas_disable_events+0x1b/0x50 [libsas]
      [<ffffffffa03e9818>] sas_unregister_ha+0x18/0x60 [libsas]
      [<ffffffffa040316e>] isci_unregister+0x1e/0x40 [isci]
      [<ffffffffa0403efd>] isci_pci_remove+0x5d/0x100 [isci]
      [<ffffffff813391cb>] pci_device_remove+0x3b/0xb0
      [<ffffffff813fbf7f>] __device_release_driver+0x7f/0xf0
      [<ffffffff813fc8f8>] driver_detach+0xa8/0xb0
      [<ffffffff813fbb8b>] bus_remove_driver+0x9b/0x120
      [<ffffffff813fcf2c>] driver_unregister+0x2c/0x50
      [<ffffffff813381f3>] pci_unregister_driver+0x23/0x80
      [<ffffffffa04152f8>] isci_exit+0x10/0x1e [isci]
      [<ffffffff810d199b>] SyS_delete_module+0x16b/0x2d0
      [<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0
      [<ffffffff8166ce29>] system_call_fastpath+0x16/0x1b
    
    The loop has been corrected.
    This patch fixes kernel panic during entering the S3 state
    and the above oops.
    
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
    Tested-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 584ec12265192bf49dfa270d517380f6723a6956
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Feb 6 12:23:01 2014 -0800

    isci: fix reset timeout handling
    
    commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.
    
    Remove an erroneous BUG_ON() in the case of a hard reset timeout.  The
    reset timeout handler puts the port into the "awaiting link-up" state.
    The timeout causes the device to be disconnected and we need to be in
    the awaiting link-up state to re-connect the port.  The BUG_ON() made
    the incorrect assumption that resets never timeout and we always
    complete the reset in the "resetting" state.
    
    Testing this patch also uncovered that libata continues to attempt to
    reset the port long after the driver has torn down the context.  Once
    the driver has committed to abandoning the link it must indicate to
    libata that recovery ends by returning -ENODEV from
    ->lldd_I_T_nexus_reset().
    
    Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Reported-by: David Milburn <dmilburn@redhat.com>
    Reported-by: Xun Ni <xun.ni@intel.com>
    Tested-by: Xun Ni <xun.ni@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3e2ac237de6938d922bb865ba3aeb01d357d6e6e
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Mar 4 11:27:38 2014 -0800

    usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
    
    commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream.
    
    The DELAY_INIT quirk only reduces the frequency of enumeration failures
    with the Logitech HD Pro C920 and C930e webcams, but does not quite
    eliminate them. We have found that adding a delay of 100ms between the
    first and second Get Configuration request makes the device enumerate
    perfectly reliable even after several weeks of extensive testing. The
    reasons for that are anyone's guess, but since the DELAY_INIT quirk
    already delays enumeration by a whole second, wating for another 10th of
    that isn't really a big deal for the one other device that uses it, and
    it will resolve the problems with these webcams.
    
    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e226584b8f1fb2499b5e884afccff2afcd49f264
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Mar 4 10:52:39 2014 -0800

    usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
    
    commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream.
    
    We've encountered a rare issue when enumerating two Logitech webcams
    after a reboot that doesn't power cycle the USB ports. They are spewing
    random data (possibly some leftover UVC buffers) on the second
    (full-sized) Get Configuration request of the enumeration phase. Since
    the data is random this can potentially cause all kinds of odd behavior,
    and since it occasionally happens multiple times (after the kernel
    issues another reset due to the garbled configuration descriptor), it is
    not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
    around the issue.
    
    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 42ca807c04bd8a48e2fd6d51b26dcebf284b1288
Author: Michele Baldessari <michele@acksyn.org>
Date:   Fri Mar 7 16:34:29 2014 +0000

    libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)
    
    commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream.
    
    Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
    for Seagate Momentus SpinPoint M8" we added a quirk for disks named
    "ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".
    
    As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
    we need to also add firmware revision 2BA30001 as it is broken as well.
    
    Reported-by: Nicholas <arealityfarbetween@googlemail.com>
    Signed-off-by: Michele Baldessari <michele@acksyn.org>
    Tested-by: Guilherme Amadio <guilherme.amadio@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0c97b887e8125a445ac220dbb3d81adb2690ccba
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Mar 4 08:31:24 2014 +1100

    powerpc: Align p_dyn, p_rela and p_st symbols
    
    commit a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67 upstream.
    
    The 64bit relocation code places a few symbols in the text segment.
    These symbols are only 4 byte aligned where they need to be 8 byte
    aligned. Add an explicit alignment.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 426a3d1bf77735722ef23691fcc7cc14c3264aef
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Mar 5 14:29:58 2014 +1100

    net: unix socket code abuses csum_partial
    
    commit 0a13404dd3bf4ea870e3d96270b5a382edca85c0 upstream.
    
    The unix socket code is using the result of csum_partial to
    hash into a lookup table:
    
    	unix_hash_fold(csum_partial(sunaddr, len, 0));
    
    csum_partial is only guaranteed to produce something that can be
    folded into a checksum, as its prototype explains:
    
     * returns a 32-bit number suitable for feeding into itself
     * or csum_tcpudp_magic
    
    The 32bit value should not be used directly.
    
    Depending on the alignment, the ppc64 csum_partial will return
    different 32bit partial checksums that will fold into the same
    16bit checksum.
    
    This difference causes the following testcase (courtesy of
    Gustavo) to sometimes fail:
    
    #include <sys/socket.h>
    #include <stdio.h>
    
    int main()
    {
    	int fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0);
    
    	int i = 1;
    	setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &i, 4);
    
    	struct sockaddr addr;
    	addr.sa_family = AF_LOCAL;
    	bind(fd, &addr, 2);
    
    	listen(fd, 128);
    
    	struct sockaddr_storage ss;
    	socklen_t sslen = (socklen_t)sizeof(ss);
    	getsockname(fd, (struct sockaddr*)&ss, &sslen);
    
    	fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0);
    
    	if (connect(fd, (struct sockaddr*)&ss, sslen) == -1){
    		perror(NULL);
    		return 1;
    	}
    	printf("OK\n");
    	return 0;
    }
    
    As suggested by davem, fix this by using csum_fold to fold the
    partial 32bit checksum into a 16bit checksum before using it.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8197077f9fc59c76180360af754741776cc803b1
Author: Amitkumar Karwar <akarwar@marvell.com>
Date:   Tue Mar 4 18:43:13 2014 -0800

    mwifiex: copy AP's HT capability info correctly
    
    commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream.
    
    While preparing association request, intersection of device's HT
    capability information and corresponding fields advertised by AP
    is used.
    
    This patch fixes an error while copying this field from AP's
    beacon.
    
    Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b3f2fbcbd031238ed9e2e3d6019397bbc164ad4
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Mar 4 13:46:53 2014 +0100

    mac80211: clear sequence/fragment number in QoS-null frames
    
    commit 864a6040f395464003af8dd0d8ca86fed19866d4 upstream.
    
    Avoid leaking data by sending uninitialized memory and setting an
    invalid (non-zero) fragment number (the sequence number is ignored
    anyway) by setting the seq_ctrl field to zero.
    
    Fixes: 3f52b7e328c5 ("mac80211: mesh power save basics")
    Fixes: ce662b44ce22 ("mac80211: send (QoS) Null if no buffered frames")
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: Drop change to mps_qos_null_get()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5433b20d60b375309b86c23d02d8c939a7333c31
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Mar 5 12:34:39 2014 +0100

    ALSA: usb-audio: Add quirk for Logitech Webcam C500
    
    commit e805ca8b0a9b6c91099c0eaa4b160a1196a4ae25 upstream.
    
    Logitech C500 (046d:0807) needs the same workaround like other
    Logitech Webcams.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 803299de13d1693823f00b6c52d1e3a987f291bb
Author: Jan Kara <jack@suse.cz>
Date:   Mon Mar 3 15:38:32 2014 -0800

    ocfs2: fix quota file corruption
    
    commit 15c34a760630ca2c803848fba90ca0646a9907dd upstream.
    
    Global quota files are accessed from different nodes.  Thus we cannot
    cache offset of quota structure in the quota file after we drop our node
    reference count to it because after that moment quota structure may be
    freed and reallocated elsewhere by a different node resulting in
    corruption of quota file.
    
    Fix the problem by clearing dq_off when we are releasing dquot structure.
    We also remove the DB_READ_B handling because it is useless -
    DQ_ACTIVE_B is set iff DQ_READ_B is set.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
    Cc: Joel Becker <jlbec@evilplan.org>
    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e9d0d0b01f89750d66f3e324607f6bb1f4db387a
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Feb 26 13:37:38 2014 -0500

    tracing: Do not add event files for modules that fail tracepoints
    
    commit 45ab2813d40d88fc575e753c38478de242d03f88 upstream.
    
    If a module fails to add its tracepoints due to module tainting, do not
    create the module event infrastructure in the debugfs directory. As the events
    will not work and worse yet, they will silently fail, making the user wonder
    why the events they enable do not display anything.
    
    Having a warning on module load and the events not visible to the users
    will make the cause of the problem much clearer.
    
    Link: http://lkml.kernel.org/r/20140227154923.265882695@goodmis.org
    
    Fixes: 6d723736e472 "tracing/events: add support for modules to TRACE_EVENT"
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 81b50572207dd2d5ebc9e1b8a203b29463b0369c
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Feb 28 20:48:36 2014 +0100

    can: flexcan: flexcan_remove(): add missing netif_napi_del()
    
    commit d96e43e8fce28cf97df576a07af9d65657a41a6f upstream.
    
    This patch adds the missing netif_napi_del() to the flexcan_remove() function.
    
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a523c634220331191acd0d3bbfce61fa4d02431b
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Feb 28 14:52:01 2014 +0100

    can: flexcan: flexcan_open(): fix error path if flexcan_chip_start() fails
    
    commit 7e9e148af01ef388efb6e2490805970be4622792 upstream.
    
    If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed,
    this patch adds the missing cleanup.
    
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5fdcc8da46cec9fc4f240dbd7ec1e70713d464cc
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Feb 19 12:00:51 2014 +0100

    can: flexcan: fix shutdown: first disable chip, then all interrupts
    
    commit 5be93bdda64e85450598c6e97f79fb8f6acf30e0 upstream.
    
    When shutting down the CAN interface (ifconfig canX down) during high CAN bus
    loads, the CAN core might hang and freeze the whole CPU.
    
    This patch fixes the shutdown sequence by first disabling the CAN core then
    disabling all interrupts.
    
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 955f8acb2df06b1e28c88dc653293f51b42eb8f0
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date:   Mon Feb 24 17:30:55 2014 +0100

    powerpc/crashdump : Fix page frame number check in copy_oldmem_page
    
    commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.
    
    In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
    decide if the page is backed or not, is not valid when the memory layout is
    not continuous.
    
    This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
    in the memory. In that case max_pfn points to the end of RTAS, and a hole
    between the end of the kdump kernel and RTAS is not backed by PTEs. As a
    consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
    in a direct way the pages in that hole.
    
    This fix relies on the memblock's service memblock_is_region_memory to
    check if the read page is part or not of the directly accessible memory.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2faa4da5e697d943efa5b8126f736df6f913496
Author: Li Zefan <lizefan@huawei.com>
Date:   Thu Feb 27 18:19:36 2014 +0800

    cpuset: fix a race condition in __cpuset_node_allowed_softwall()
    
    commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream.
    
    It's not safe to access task's cpuset after releasing task_lock().
    Holding callback_mutex won't help.
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b80b8d77f13e7d8a88179a208b839b31a9f667d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Feb 24 12:06:12 2014 +0100

    perf: Fix hotplug splat
    
    commit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream.
    
    Drew Richardson reported that he could make the kernel go *boom* when hotplugging
    while having perf events active.
    
    It turned out that when you have a group event, the code in
    __perf_event_exit_context() fails to remove the group siblings from
    the context.
    
    We then proceed with destroying and freeing the event, and when you
    re-plug the CPU and try and add another event to that CPU, things go
    *boom* because you've still got dead entries there.
    
    Reported-by: Drew Richardson <drew.richardson@arm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43e2f50d5845b7bc29e3ccf464144c66d2eab7da
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Feb 21 16:03:12 2014 +0100

    perf/x86: Fix event scheduling
    
    commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.
    
    Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
    with perf WARN_ON()s triggering. He also provided traces of the failures.
    
    This is I think the relevant bit:
    
    	>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_disable: x86_pmu_disable
    	>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_state: Events: {
    	>    pec_1076_warn-2804  [000] d...   147.926156: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
    	>    pec_1076_warn-2804  [000] d...   147.926158: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
    	>    pec_1076_warn-2804  [000] d...   147.926159: x86_pmu_state: }
    	>    pec_1076_warn-2804  [000] d...   147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
    	>    pec_1076_warn-2804  [000] d...   147.926161: x86_pmu_state: Assignment: {
    	>    pec_1076_warn-2804  [000] d...   147.926162: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
    	>    pec_1076_warn-2804  [000] d...   147.926163: x86_pmu_state: }
    	>    pec_1076_warn-2804  [000] d...   147.926166: collect_events: Adding event: 1 (ffff880119ec8800)
    
    So we add the insn:p event (fd[23]).
    
    At this point we should have:
    
      n_events = 2, n_added = 1, n_txn = 1
    
    	>    pec_1076_warn-2804  [000] d...   147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
    	>    pec_1076_warn-2804  [000] d...   147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)
    
    We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
    These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
    that's not visible.
    
    	group_sched_in()
    	  pmu->start_txn() /* nop - BP pmu */
    	  event_sched_in()
    	     event->pmu->add()
    
    So here we should end up with:
    
      0: n_events = 3, n_added = 2, n_txn = 2
      4: n_events = 4, n_added = 3, n_txn = 3
    
    But seeing the below state on x86_pmu_enable(), the must have failed,
    because the 0 and 4 events aren't there anymore.
    
    Looking at group_sched_in(), since the BP is the leader, its
    event_sched_in() must have succeeded, for otherwise we would not have
    seen the sibling adds.
    
    But since neither 0 or 4 are in the below state; their event_sched_in()
    must have failed; but I don't see why, the complete state: 0,0,1:p,4
    fits perfectly fine on a core2.
    
    However, since we try and schedule 4 it means the 0 event must have
    succeeded!  Therefore the 4 event must have failed, its failure will
    have put group_sched_in() into the fail path, which will call:
    
    	event_sched_out()
    	  event->pmu->del()
    
    on 0 and the BP event.
    
    Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
    giving what we see below:
    
     n_event = 2, n_added = 2, n_txn = 2
    
    	>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_enable: x86_pmu_enable
    	>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_state: Events: {
    	>    pec_1076_warn-2804  [000] d...   147.926179: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
    	>    pec_1076_warn-2804  [000] d...   147.926181: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
    	>    pec_1076_warn-2804  [000] d...   147.926182: x86_pmu_state: }
    	>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
    	>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: Assignment: {
    	>    pec_1076_warn-2804  [000] d...   147.926186: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
    	>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state:   1->0 tag: 1 config: 1 (ffff880119ec8800)
    	>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state: }
    	>    pec_1076_warn-2804  [000] d...   147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0
    
    So the problem is that x86_pmu_del(), when called from a
    group_sched_in() that fails (for whatever reason), and without x86_pmu
    TXN support (because the leader is !x86_pmu), will corrupt the n_added
    state.
    
    Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0f495447dae6713f0d3f37b5db749655111d48d
Author: George McCollister <george.mccollister@gmail.com>
Date:   Tue Feb 18 17:56:51 2014 -0600

    sched: Fix double normalization of vruntime
    
    commit 791c9e0292671a3bfa95286bb5c08129d8605618 upstream.
    
    dequeue_entity() is called when p->on_rq and sets se->on_rq = 0
    which appears to guarentee that the !se->on_rq condition is met.
    If the task has done set_current_state(TASK_INTERRUPTIBLE) without
    schedule() the second condition will be met and vruntime will be
    incorrectly adjusted twice.
    
    In certain cases this can result in the task's vruntime never increasing
    past the vruntime of other tasks on the CFS' run queue, starving them of
    CPU time.
    
    This patch changes switched_from_fair() to use !p->on_rq instead of
    !se->on_rq.
    
    I'm able to cause a task with a priority of 120 to starve all other
    tasks with the same priority on an ARM platform running 3.2.51-rt72
    PREEMPT RT by writing one character at time to a serial tty (16550 UART)
    in a tight loop. I'm also able to verify making this change corrects the
    problem on that platform and kernel version.
    
    Signed-off-by: George McCollister <george.mccollister@gmail.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1392767811-28916-1-git-send-email-george.mccollister@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2b6e97e6748795e47ec139f4da96b2f2d16bb8ee
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Mon Feb 24 11:29:50 2014 +0800

    genirq: Remove racy waitqueue_active check
    
    commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream.
    
    We hit one rare case below:
    
    T1 calling disable_irq(), but hanging at synchronize_irq()
    always;
    The corresponding irq thread is in sleeping state;
    And all CPUs are in idle state;
    
    After analysis, we found there is one possible scenerio which
    causes T1 is waiting there forever:
    CPU0                                       CPU1
     synchronize_irq()
      wait_event()
        spin_lock()
                                               atomic_dec_and_test(&threads_active)
          insert the __wait into queue
        spin_unlock()
                                               if(waitqueue_active)
        atomic_read(&threads_active)
                                                 wake_up()
    
    Here after inserted the __wait into queue on CPU0, and before
    test if queue is empty on CPU1, there is no barrier, it maybe
    cause it is not visible for CPU1 immediately, although CPU0 has
    updated the queue list.
    It is similar for CPU0 atomic_read() threads_active also.
    
    So we'd need one smp_mb() before waitqueue_active.that, but removing
    the waitqueue_active() check solves it as wel l and it makes
    things simple and clear.
    
    Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Cc: Xiaoming Wang <xiaoming.wang@intel.com>
    Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.2: The corresponding check is in irq_thread()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7d1cce6a938cad067edbb4522b587df60afc4730
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Feb 25 10:37:15 2014 +0100

    iwlwifi: fix TX status for aggregated packets
    
    commit 143582c6847cb285b361804c613127c25de60ca4 upstream.
    
    Only the first packet is currently handled correctly, but then
    all others are assumed to have failed which is problematic. Fix
    this, marking them all successful instead (since if they're not
    then the firmware will have transmitted them as single frames.)
    
    This fixes the lost packet reporting.
    
    Also do a tiny variable scoping cleanup.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [Add the dvm part]
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    [bwh: Backported to 3.2:
     - Drop the mvm part
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 077f632633e0d19353b1140afcda3c6635202a32
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Feb 27 07:41:32 2014 +0100

    ASoC: sta32x: Fix wrong enum for limiter2 release rate
    
    commit b3619b288b621e63f66908045f48495869a996a6 upstream.
    
    There is a typo in the Limiter2 Release Rate control, a wrong enum for
    Limiter1 is assigned.  It must point to Limiter2.
    Spotted by a compile warning:
    
    In file included from sound/soc/codecs/sta32x.c:34:0:
    sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
     static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
                                 ^
    include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
      struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
                      ^
    sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
     static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
            ^
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0986dc71fb09d9916d5579c8c5e2f2c8099337d0
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Feb 19 10:29:01 2014 +0100

    usb: ehci: fix deadlock when threadirqs option is used
    
    commit a1227f3c1030e96ebc51d677d2f636268845c5fb upstream.
    
    ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
    threadirqs option is used. To prevent the deadlock use
    spin_lock_irqsave() in ehci_irq().
    
    This change can be reverted when hrtimer callbacks become threaded.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 05e327077e173bb8128d18cee8105b5d19d02ea3
Author: Joerg Dorchain <joerg@dorchain.net>
Date:   Fri Feb 21 20:29:33 2014 +0100

    USB: ftdi_sio: add Cressi Leonardo PID
    
    commit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream.
    
    Hello,
    
    the following patch adds an entry for the PID of a Cressi Leonardo
    diving computer interface to kernel 3.13.0.
    It is detected as FT232RL.
    Works with subsurface.
    
    Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ce0dc52a75aced1c49c2e51fcab7c8922742a93
Author: Алексей Крамаренко <alexeyk13@yandex.ru>
Date:   Fri Nov 1 17:26:38 2013 +0400

    USB: serial: ftdi_sio: add id for Z3X Box device
    
    commit e1466ad5b1aeda303f9282463d55798d2eda218c upstream.
    
    Custom VID/PID for Z3X Box device, popular tool for cellphone flashing.
    
    Signed-off-by: Alexey E. Kramarenko <alexeyk13@yandex.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc07f983deb9895504eb35c0970e0abecd57960a
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Wed Feb 26 21:03:05 2014 +0800

    ACPI / processor: Rework processor throttling with work_on_cpu()
    
    commit f3ca4164529b875374c410193bbbac0ee960895f upstream.
    
    acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
    sure that the (struct acpi_processor)->acpi_processor_set_throttling()
    callback will run on the right CPU.  However, the function may be
    called from a worker thread already bound to a different CPU in which
    case that won't work.
    
    Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
    instead of abusing set_cpus_allowed_ptr().
    
    Reported-and-tested-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    [rjw: Changelog]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0ece81d888e6860fccf8114c71b57f36f5f26afc
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Feb 19 16:19:35 2014 -0800

    ioat: fix tasklet tear down
    
    commit da87ca4d4ca101f177fffd84f1f0a5e4c0343557 upstream.
    
    Since commit 77873803363c "net_dma: mark broken" we no longer pin dma
    engines active for the network-receive-offload use case.  As a result
    the ->free_chan_resources() that occurs after the driver self test no
    longer has a NET_DMA induced ->alloc_chan_resources() to back it up.  A
    late firing irq can lead to ksoftirqd spinning indefinitely due to the
    tasklet_disable() performed by ->free_chan_resources().  Only
    ->alloc_chan_resources() can clear this condition in affected kernels.
    
    This problem has been present since commit 3e037454bcfa "I/OAT: Add
    support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
    NET_DMA use case is deprecated we can revisit moving the driver to use
    threaded irqs.  For now, just tear down the irq and tasklet properly by:
    
    1/ Disable the irq from triggering the tasklet
    
    2/ Disable the irq from re-arming
    
    3/ Flush inflight interrupts
    
    4/ Flush the timer
    
    5/ Flush inflight tasklets
    
    References:
    https://lkml.org/lkml/2014/1/27/282
    https://lkml.org/lkml/2014/2/19/672
    
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Reported-by: Mike Galbraith <bitbucket@online.de>
    Reported-by: Stanislav Fomichev <stfomichev@yandex-team.ru>
    Tested-by: Mike Galbraith <bitbucket@online.de>
    Tested-by: Stanislav Fomichev <stfomichev@yandex-team.ru>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - As there is no ioatdma_device::irq_mode member, check
       pci_dev::msix_enabled instead]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Acked-by: Dan Williams <dan.j.williams@intel.com>

commit 31106f91a6e0efe9997c251b037370204e66e9db
Author: Jean Delvare <jdelvare@suse.de>
Date:   Tue Feb 25 09:43:13 2014 +0100

    i7300_edac: Fix device reference count
    
    commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream.
    
    pci_get_device() decrements the reference count of "from" (last
    argument) so when we break off the loop successfully we have only one
    device reference - and we don't know which device we have. If we want
    a reference to each device, we must take them explicitly and let
    the pci_get_device() walk complete to avoid duplicate references.
    
    This is serious, as over-putting device references will cause
    the device to eventually disappear. Without this fix, the kernel
    crashes after a few insmod/rmmod cycles.
    
    Tested on an Intel S7000FC4UR system with a 7300 chipset.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare
    Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Cc: Doug Thompson <dougthompson@xmission.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fe82db3eeece2ed4686f573356ed5c396f99fa96
Author: Jean Delvare <jdelvare@suse.de>
Date:   Mon Feb 24 09:39:27 2014 +0100

    i7core_edac: Fix PCI device reference count
    
    commit c0f5eeed0f4cef4f05b74883a7160e7edde58b6a upstream.
    
    The reference count changes done by pci_get_device can be a little
    misleading when the usage diverges from the most common scheme. The
    reference count of the device passed as the last parameter is always
    decreased, even if the function returns no new device. So if we are
    going to try alternative device IDs, we must manually increment the
    device reference count before each retry. If we don't, we end up
    decreasing the reference count, and after a few modprobe/rmmod cycles
    the PCI devices will vanish.
    
    In other words and as Alan put it: without this fix the EDAC code
    corrupts the PCI device list.
    
    This fixes kernel bug #50491:
    https://bugzilla.kernel.org/show_bug.cgi?id=50491
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvare
    Reviewed-by: Alan Cox <alan@linux.intel.com>
    Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Cc: Doug Thompson <dougthompson@xmission.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7149a5e5c1fecc22a838f87ed86bfa3cc0efc984
Author: Jan Kara <jack@suse.cz>
Date:   Thu Feb 20 17:02:27 2014 +0100

    quota: Fix race between dqput() and dquot_scan_active()
    
    commit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream.
    
    Currently last dqput() can race with dquot_scan_active() causing it to
    call callback for an already deactivated dquot. The race is as follows:
    
    CPU1					CPU2
      dqput()
        spin_lock(&dq_list_lock);
        if (atomic_read(&dquot->dq_count) > 1) {
         - not taken
        if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
          spin_unlock(&dq_list_lock);
          ->release_dquot(dquot);
            if (atomic_read(&dquot->dq_count) > 1)
             - not taken
    					  dquot_scan_active()
    					    spin_lock(&dq_list_lock);
    					    if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))
    					     - not taken
    					    atomic_inc(&dquot->dq_count);
    					    spin_unlock(&dq_list_lock);
            - proceeds to release dquot
    					    ret = fn(dquot, priv);
    					     - called for inactive dquot
    
    Fix the problem by making sure possible ->release_dquot() is finished by
    the time we call the callback and new calls to it will notice reference
    dquot_scan_active() has taken and bail out.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cf5a6031f2bd8799ad551fb9b65f1b1e3104ea8a
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Fri Feb 14 08:15:20 2014 +0530

    ath9k: Fix ETSI compliance for AR9462 2.0
    
    commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream.
    
    The minimum CCA power threshold values have to be adjusted
    for existing cards to be in compliance with new regulations.
    Newer cards will make use of the values obtained from EEPROM,
    support for this was added earlier. To make sure that cards
    that are already in use and don't have proper values in EEPROM,
    do not violate regulations, use the initvals instead.
    
    Reported-by: Jeang Daniel <dyjeong@qca.qualcomm.com>
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cf117670cf074367290d5993fe3111ac6d6b1777
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Feb 19 13:15:17 2014 +0100

    ath9k: protect tid->sched check
    
    commit 21f8aaee0c62708654988ce092838aa7df4d25d8 upstream.
    
    We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
    is race condition which can result of doing list_del(&tid->list) twice
    (second time with poisoned list node) and cause crash like shown below:
    
    [424271.637220] BUG: unable to handle kernel paging request at 00100104
    [424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k]
    ...
    [424271.639953] Call Trace:
    [424271.639998]  [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k]
    [424271.640083]  [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k]
    [424271.640177]  [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211]
    [424271.640258]  [<c10f730e>] ? free_compound_page+0x2e/0x40
    [424271.640346]  [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211]
    [424271.640437]  [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0
    [424271.640510]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
    [424271.640578]  [<c10fc23c>] ? put_page+0x2c/0x40
    [424271.640640]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
    [424271.640706]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
    [424271.640787]  [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211]
    [424271.640897]  [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211]
    [424271.641009]  [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211]
    [424271.641104]  [<c13846ce>] ? ip_output+0x7e/0xd0
    [424271.641182]  [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211]
    [424271.641266]  [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k]
    [424271.641358]  [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211]
    [424271.641445]  [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k]
    
    Bug report:
    https://bugzilla.kernel.org/show_bug.cgi?id=70551
    
    Reported-and-tested-by: Max Sydorenko <maxim.stargazer@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use spin_unlock_bh() directly]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2968ef3f71236c3bee3f1c1d2f97469642fb1d9f
Author: Eric Paris <eparis@redhat.com>
Date:   Thu Feb 20 10:56:45 2014 -0500

    SELinux: bigendian problems with filename trans rules
    
    commit 9085a6422900092886da8c404e1c5340c4ff1cbf upstream.
    
    When writing policy via /sys/fs/selinux/policy I wrote the type and class
    of filename trans rules in CPU endian instead of little endian.  On
    x86_64 this works just fine, but it means that on big endian arch's like
    ppc64 and s390 userspace reads the policy and converts it from
    le32_to_cpu.  So the values are all screwed up.  Write the values in le
    format like it should have been to start.
    
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad64b463d919a18be70b281efb135231169caf4a
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Feb 20 09:22:11 2014 +0200

    mac80211: fix AP powersave TX vs. wakeup race
    
    commit 1d147bfa64293b2723c4fec50922168658e613ba upstream.
    
    There is a race between the TX path and the STA wakeup: while
    a station is sleeping, mac80211 buffers frames until it wakes
    up, then the frames are transmitted. However, the RX and TX
    path are concurrent, so the packet indicating wakeup can be
    processed while a packet is being transmitted.
    
    This can lead to a situation where the buffered frames list
    is emptied on the one side, while a frame is being added on
    the other side, as the station is still seen as sleeping in
    the TX path.
    
    As a result, the newly added frame will not be send anytime
    soon. It might be sent much later (and out of order) when the
    station goes to sleep and wakes up the next time.
    
    Additionally, it can lead to the crash below.
    
    Fix all this by synchronising both paths with a new lock.
    Both path are not fastpath since they handle PS situations.
    
    In a later patch we'll remove the extra skb queue locks to
    reduce locking overhead.
    
    BUG: unable to handle kernel
    NULL pointer dereference at 000000b0
    IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
    *pde = 00000000
    Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
    EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
    EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
    EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
    ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
    DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    DR6: ffff0ff0 DR7: 00000400
    Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
    iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
    Stack:
     e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
     ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
     ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
    Call Trace:
     [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
     [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
     [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
     [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
     [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
     [<c149ef70>] dev_hard_start_xmit+0x450/0x950
     [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
     [<c14b9c9b>] __qdisc_run+0x4b/0x150
     [<c149f732>] dev_queue_xmit+0x2c2/0xca0
    
    Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
    [reword commit log, use a separate lock]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ec5f1fb179c8f79246034259e36881a3d3186d1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 18 09:37:30 2014 +0100

    ASoC: wm8770: Fix wrong number of enum items
    
    commit 7a6c0a58dc824523966f212c76322d47c5b0e6fe upstream.
    
    wm8770 codec driver defines ain_enum with a wrong number of items.
    
    Use SOC_ENUM_DOUBLE_DECL() macro and it's automatically fixed.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 768b167b17003911a613fde3acbcbc273462e405
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Feb 13 16:32:51 2014 +0100

    ACPI / video: Filter the _BCL table for duplicate brightness values
    
    commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.
    
    Some devices have duplicate entries in there brightness levels table, ie
    on my Dell Latitude E6430 the table looks like this:
    
    [    3.686060] acpi backlight index   0, val 80
    [    3.686095] acpi backlight index   1, val 50
    [    3.686122] acpi backlight index   2, val 5
    [    3.686147] acpi backlight index   3, val 5
    [    3.686172] acpi backlight index   4, val 5
    [    3.686197] acpi backlight index   5, val 5
    [    3.686223] acpi backlight index   6, val 5
    [    3.686248] acpi backlight index   7, val 5
    [    3.686273] acpi backlight index   8, val 6
    [    3.686332] acpi backlight index   9, val 7
    [    3.686356] acpi backlight index  10, val 8
    [    3.686380] acpi backlight index  11, val 9
    etc.
    
    Notice that brightness values 0-5 are all mapped to 5. This means that
    if userspace writes any value between 0 and 5 to the brightness sysfs attribute
    and then reads it, it will always return 0, which is somewhat unexpected.
    
    This is a problem for ie gnome-settings-daemon, which uses read-modify-write
    logic when the users presses the brightness up or down keys. This is done
    this way to take brightness changes from other sources into account.
    
    On this specific laptop what happens once the brightness has been set to 0,
    is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
    again reads 0, so things get stuck at the lowest brightness setting.
    
    Filtering out the duplicate table entries, makes any write to brightness
    read back as the written value as one would expect, fixing this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 270bcf0672347f19f6214802c1842fa1e6d9fd2d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 18 09:24:12 2014 +0100

    ASoC: sta32x: Fix array access overflow
    
    commit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream.
    
    Preset EQ enum of sta32x codec driver declares too many number of
    items and it may lead to the access over the actual array size.
    
    Use SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8553a06b06825d49b4727c8ce4c54bd6f3d873a8
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Feb 15 17:54:06 2014 -0800

    hwmon: (max1668) Fix writing the minimum temperature
    
    commit 500a91571f0a5d0d3242d83802ea2fd1faccc66e upstream.
    
    When trying to set the minimum temperature, the driver was erroneously
    writing the maximum temperature into the chip.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a320419451b152ce343bd59675a5bfa0beffe9e9
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Feb 13 13:29:31 2014 -0500

    cgroup: update cgroup_enable_task_cg_lists() to grab siglock
    
    commit 532de3fc72adc2a6525c4d53c07bf81e1732083d upstream.
    
    Currently, there's nothing preventing cgroup_enable_task_cg_lists()
    from missing set PF_EXITING and race against cgroup_exit().  Depending
    on the timing, cgroup_exit() may finish with the task still linked on
    css_set leading to list corruption.  Fix it by grabbing siglock in
    cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be
    visible.
    
    This whole on-demand cg_list optimization is extremely fragile and has
    ample possibility to lead to bugs which can cause things like
    once-a-year oops during boot.  I'm wondering whether the better
    approach would be just adding "cgroup_disable=all" handling which
    disables the whole cgroup rather than tempting fate with this
    on-demand craziness.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Li Zefan <lizefan@huawei.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c37145e29e4cd71a5aff0e2bb5837e821d538c16
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Sat Feb 15 22:02:28 2014 +0800

    workqueue: ensure @task is valid across kthread_stop()
    
    commit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream.
    
    When a kworker should die, the kworkre is notified through WORKER_DIE
    flag instead of kthread_should_stop().  This, IIRC, is primarily to
    keep the test synchronized inside worker_pool lock.  WORKER_DIE is
    first set while holding pool->lock, the lock is dropped and
    kthread_stop() is called.
    
    Unfortunately, this means that there's a slight chance that the target
    kworker may see WORKER_DIE before kthread_stop() finishes and exits
    and frees the target task before or during kthread_stop().
    
    Fix it by pinning the target task before setting WORKER_DIE and
    putting it after kthread_stop() is done.
    
    tj: Improved patch description and comment.  Moved pinning above
        WORKER_DIE for better signify what it's protecting.
    
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b33d2a11535e4dcb42724a0c4e3156ab3531110
Author: Aleksander Morgado <aleksander@aleksander.es>
Date:   Wed Feb 12 16:04:45 2014 +0100

    USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
    
    commit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream.
    
    This interface is to be handled by the qmi_wwan driver.
    
    CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
    CC: Christian Schmiedl <christian.schmiedl@gemalto.com>
    CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com>
    CC: David McCullough <david.mccullough@accelecon.com>
    Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b9ba959f2b51aeb0527d1445982e287272134f0b
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Feb 13 15:49:17 2014 -0500

    USB: EHCI: add delay during suspend to prevent erroneous wakeups
    
    commit 3e8d6d85adedc59115a564c0a54b36e42087c4d9 upstream.
    
    High-speed USB connections revert back to full-speed signalling when
    the device goes into suspend.  This takes several milliseconds, and
    during that time it's not possible to tell reliably whether the device
    has been disconnected.
    
    On some platforms, the Wake-On-Disconnect circuitry gets confused
    during this intermediate state.  It generates a false wakeup signal,
    which can prevent the controller from going to sleep.
    
    To avoid this problem, this patch adds a 5-ms delay to the
    ehci_bus_suspend() routine if any ports have to switch over to
    full-speed signalling.  (Actually, the delay was already present for
    devices using a particular kind of PHY power management; the patch
    merely causes the delay to be used more widely.)
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reviewed-by: Peter Chen <Peter.Chen@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/has_tdi_phy_lpm/has_hostpc/
     - Always re-lock ehci->lock after the sleep]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4da411ab87cfe8e7ae19da2544eca690282f56f0
Author: Levente Kurusa <levex@linux.com>
Date:   Tue Feb 18 10:22:17 2014 -0500

    ahci: disable NCQ on Samsung pci-e SSDs on macbooks
    
    commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.
    
    Samsung's pci-e SSDs with device ID 0x1600 which are found on some
    macbooks time out on NCQ commands.  Blacklist NCQ on the device so
    that the affected machines can at least boot.
    
    Original-patch-by: Levente Kurusa <levex@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e485fec7439abbdbd722441a2b6060cf7d6feffe
Author: Vinayak Kale <vkale@apm.com>
Date:   Wed Feb 12 07:30:01 2014 +0100

    ARM: 7957/1: add DSB after icache flush in __flush_icache_all()
    
    commit 39544ac9df20f73e49fc6b9ac19ff533388c82c0 upstream.
    
    Add DSB after icache flush to complete the cache maintenance operation.
    
    Signed-off-by: Vinayak Kale <vkale@apm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6f1c78ae9ea925593f4e47500eec579aa2fbdc07
Author: Chen Gang <gang.chen.5i5j@gmail.com>
Date:   Sat Feb 1 20:35:54 2014 +0800

    avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use
    
    commit 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 upstream.
    
    For avr32 cross compiler, do not define '__linux__' internally, so it
    will cause issue with allmodconfig.
    
    The related error:
    
        CC [M]  fs/coda/psdev.o
      In file included from include/linux/coda.h:64,
                       from fs/coda/psdev.c:45:
      include/uapi/linux/coda.h:221: error: expected specifier-qualifier-list before 'u_quad_t'
    
    The related toolchain version (which only download, not re-compile):
    
      [root@gchen linux-next]# /upstream/toolchain/download/avr32-gnu-toolchain-linux_x86/bin/avr32-gcc -v
      Using built-in specs.
      Target: avr32
      Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/src/gcc/configure --target=avr32 --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-languages=c,c++ --disable-nls --disable-libssp --disable-libstdcxx-pch --with-dwarf2 --enable-version-specific-runtime-libs --disable-shared --enable-doc --with-mpfr-lib=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/lib --with-mpfr-include=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/include --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-__cxa_atexit --disable-shared --with-newlib --with-pkgversion=AVR_32_bit_GNU_Toolchain_3.4.2_435 --with-bugurl=http://www
    .atmel.com/avr
      Thread model: single
      gcc version 4.4.7 (AVR_32_bit_GNU_Toolchain_3.4.2_435)
    
    Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
    Acked-by: Hans-Christian Egtvedt <hegtvedt@cisco.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3ed5f0ea41e40e65ea75545b7366bb365c0e1a9c
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Jan 10 09:29:39 2014 -0500

    avr32: fix missing module.h causing build failure in mimc200/fram.c
    
    commit 5745d6a41a4f4aec29e2ccd591c6fb09ed73a955 upstream.
    
    Causing this:
    
    In file included from arch/avr32/boards/mimc200/fram.c:13:
    include/linux/miscdevice.h:51: error: field 'list' has incomplete type
    include/linux/miscdevice.h:55: error: expected specifier-qualifier-list before 'mode_t'
    arch/avr32/boards/mimc200/fram.c:42: error: 'THIS_MODULE' undeclared here (not in a function)
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
    Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41c625d7d7b8d7e2626011794c3f0a6fcca0c342
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sun Feb 16 17:11:10 2014 +0100

    ALSA: usb-audio: work around KEF X300A firmware bug
    
    commit 624aef494f86ed0c58056361c06347ad62b26806 upstream.
    
    When the driver tries to access Function Unit 10, the KEF X300A
    speakers' firmware apparently locks up, making even PCM streaming
    impossible.  Work around this by ignoring this FU.
    
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 74f925dea76124060a2021460a26c6ddc815bfff
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Feb 13 10:39:01 2014 +0100

    dma: ste_dma40: don't dereference free:d descriptor
    
    commit e9baa9d9d520fb0e24cca671e430689de2d4a4b2 upstream.
    
    It appears that in the DMA40 driver the DMA tasklet will very
    often dereference memory for a descriptor just free:d from the
    DMA40 slab. Nothing happens because no other part of the driver
    has yet had a chance to claim this memory, but it's really
    nasty to dereference free:d memory, so let's check the flag
    before the descriptor is free and store it in a bool variable.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 426f6c8a5051be7dafe96dba65ff73b778ba7839
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Feb 16 19:29:32 2014 -0500

    ext4: don't leave i_crtime.tv_sec uninitialized
    
    commit 19ea80603715d473600cd993b9987bc97d042e02 upstream.
    
    If the i_crtime field is not present in the inode, don't leave the
    field uninitialized.
    
    Fixes: ef7f38359 ("ext4: Add nanosecond timestamps")
    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
    Tested-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 59a3ae82e4a6235e8edf23881dad8aa70a802df9
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Feb 14 13:48:16 2014 -0700

    PCI: Enable INTx if BIOS left them disabled
    
    commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream.
    
    Some firmware leaves the Interrupt Disable bit set even if the device uses
    INTx interrupts.  Clear Interrupt Disable so we get those interrupts.
    
    Based on the report mentioned below, if the user selects the "EHCI only"
    option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
    with the PCI_COMMAND_INTX_DISABLE bit set.
    
    Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601
    Reported-by: Chris Cheng <chris.cheng@atrustcorp.com>
    Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fff691886ed8c83d3ba90e097f1b2c241d11c5e7
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Feb 12 18:15:00 2014 +0100

    EDAC: Correct workqueue setup path
    
    commit cb6ef42e516cb8948f15e4b70dc03af8020050a2 upstream.
    
    We're using edac_mc_workq_setup() both on the init path, when
    we load an edac driver and when we change the polling period
    (edac_mc_reset_delay_period) through /sys/.../edac_mc_poll_msec.
    
    On that second path we don't need to init the workqueue which has been
    initialized already.
    
    Thanks to Tejun for workqueue insights.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/1391457913-881-1-git-send-email-prarit@redhat.com
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d7847e1d484d1669ec3576d222fcbb7d078d1b69
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Feb 12 11:54:15 2014 -0500

    IB/qib: Add missing serdes init sequence
    
    commit 2f75e12c4457a9b3d042c0a0d748fa198dc2ffaf upstream.
    
    Research has shown that commit a77fcf895046 ("IB/qib: Use a single
    txselect module parameter for serdes tuning") missed a key serdes init
    sequence.
    
    This patch add that sequence.
    
    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: Ben Hutchings <ben@decadent.org.uk>

commit 5b9f9b8ecf9439b440d833329e0fb8c52cd5f245
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:   Mon Feb 10 22:38:28 2014 +0100

    rtl8187: fix regression on MIPS without coherent DMA
    
    commit b6213e413a4e0c66548153516b074df14f9d08e0 upstream.
    
    This patch fixes regression caused by commit a16dad77634 "MIPS: Fix
    potencial corruption". That commit fixes one corruption scenario in
    cost of adding another one, which actually start to cause crashes
    on Yeeloong laptop when rtl8187 driver is used.
    
    For correct DMA read operation on machines without DMA coherence, kernel
    have to invalidate cache, such it will refill later with new data that
    device wrote to memory, when that data is needed to process. We can only
    invalidate full cache line. Hence when cache line includes both dma
    buffer and some other data (written in cache, but not yet in main
    memory), the other data can not hit memory due to invalidation. That
    happen on rtl8187 where struct rtl8187_priv fields are located just
    before and after small buffers that are passed to USB layer and DMA
    is performed on them.
    
    To fix the problem we align buffers and reserve space after them to make
    them match cache line.
    
    This patch does not resolve all possible MIPS problems entirely, for
    that we have to assure that we always map cache aligned buffers for DMA,
    what can be complex or even not possible. But patch fixes visible and
    reproducible regression and seems other possible corruptions do not
    happen in practice, since Yeeloong laptop works stable without rtl8187
    driver.
    
    Bug report:
    https://bugzilla.kernel.org/show_bug.cgi?id=54391
    
    Reported-by: Petr Pisar <petr.pisar@atlas.cz>
    Bisected-by: Tom Li <biergaizi2009@gmail.com>
    Reported-and-tested-by: Tom Li <biergaizi2009@gmail.com>
    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.next>
    Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b280aaa4ce04a6ab491fc9dc7eb4091336fd91ec
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Sat Jun 9 20:48:47 2012 +0100

    MIPS: Fix potencial corruption
    
    commit a16dad7763420a3b46cff1e703a9070827796cfc upstream.
    
    Normally r4k_dma_cache_inv should only ever be called with cacheline
    aligned addresses.  If however, it isn't there is the theoretical
    possibility of data corruption.  There is no correct way of handling this
    and anyway, it should only happen if the DMA API is used incorrectly
    so drop
    
    There is a different corruption scenario with these CACHE instructions
    removed but again there is no way of handling this correctly and it can
    be triggered only through incorrect use of the DMA API.
    
    So just get rid of the complexity.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Reported-by: James Rodriguez <jamesr@juniper.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2de2c2e956dbf164c5acb1dca16e9a3c1938096e
Author: Olivier Langlois <olivier@trillion01.com>
Date:   Sat Feb 1 01:11:09 2014 -0500

    rtlwifi: rtl8192ce: Fix too long disable of IRQs
    
    commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 upstream.
    
    rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
    
    The observable symptoms in dmesg can be:
    
    - underruns from ALSA playback
    - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
    
    [  250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
    [  250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
    [  250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
    [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
    [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
    [  250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
    [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
    [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
    [  250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
    [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
    [  250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
    [  250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
    [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
    [  250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
    [  251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
    
    The exact code flow that causes that is:
    
    1. wpa_supplicant send a start_scan request to the nl80211 driver
    2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
    3.   rtl_ips_nic_on is called which disable local irqs
    4.     rtl92c_phy_set_rf_power_state() is called
    5.       rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
    
    A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
    but a quick and dirty solution that has proven to work is
    to reenable the irqs during the function rtl92ce_hw_init().
    
    I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
    
    Signed-off-by: Olivier Langlois <olivier@trillion01.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be1dad9009c25d4d7c1a4ff61583868f42d25257
Author: NeilBrown <neilb@suse.de>
Date:   Fri Feb 7 17:10:26 2014 +1100

    lockd: send correct lock when granting a delayed lock.
    
    commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream.
    
    If an NFS client attempts to get a lock (using NLM) and the lock is
    not available, the server will remember the request and when the lock
    becomes available it will send a GRANT request to the client to
    provide the lock.
    
    If the client already held an adjacent lock, the GRANT callback will
    report the union of the existing and new locks, which can confuse the
    client.
    
    This happens because __posix_lock_file (called by vfs_lock_file)
    updates the passed-in file_lock structure when adjacent or
    over-lapping locks are found.
    
    To avoid this problem we take a copy of the two fields that can
    be changed (fl_start and fl_end) before the call and restore them
    afterwards.
    An alternate would be to allocate a 'struct file_lock', initialise it,
    use locks_copy_lock() to take a copy, then locks_release_private()
    after the vfs_lock_file() call.  But that is a lot more work.
    
    Reported-by: Olaf Kirch <okir@suse.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    
    --
    v1 had a couple of issues (large on-stack struct and didn't really work properly).
    This version is much better tested.
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7b269a7ff58af01cf5c031a31eeb9c4579aabae
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Feb 11 11:52:05 2014 +0200

    drm/i915/dp: add native aux defer retry limit
    
    commit f51a44b9a6c4982cc25bfb3727de9bb893621ebc upstream.
    
    Retrying indefinitely places too much trust on the aux implementation of
    the sink devices.
    
    Reported-by: Daniel Martin <consume.noise@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: Theodore Ts'o <tytso@mit.edu>
    Tested-by: Sree Harsha Totakura <freedesktop@h.totakura.in>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 531a799a2088e138937baa9b2e4e3ef883276a47
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Feb 11 11:52:04 2014 +0200

    drm/i915/dp: increase native aux defer retry timeout
    
    commit 04eada25d1f72efdecd32d702706594f81de65d5 upstream.
    
    Give more slack to sink devices before retrying on native aux
    defer. AFAICT the 100 us timeout was not based on the DP spec.
    
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit feb4b89167c7db378c49ddd3062dbe2f9497a518
Author: Steven Noonan <steven@uplinklabs.net>
Date:   Wed Feb 12 23:01:07 2014 -0800

    compiler/gcc4: Make quirk for asm_volatile_goto() unconditional
    
    commit a9f180345f5378ac87d80ed0bea55ba421d83859 upstream.
    
    I started noticing problems with KVM guest destruction on Linux
    3.12+, where guest memory wasn't being cleaned up. I bisected it
    down to the commit introducing the new 'asm goto'-based atomics,
    and found this quirk was later applied to those.
    
    Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
    known 'asm goto' bug) I am still getting some kind of
    miscompilation. If I enable the asm_volatile_goto quirk for my
    compiler, KVM guests are destroyed correctly and the memory is
    cleaned up.
    
    So make the quirk unconditional for now, until bug is found
    and fixed.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Steven Noonan <steven@uplinklabs.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
    Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 778c4783df0ff6dcc120fe5c1dc9b6afa1980cd0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Feb 6 03:42:45 2014 +0530

    md/raid5: Fix CPU hotplug callback registration
    
    commit 789b5e0315284463617e106baad360cb9e8db3ac upstream.
    
    Subsystems that want to register CPU hotplug callbacks, as well as perform
    initialization for the CPUs that are already online, often do it as shown
    below:
    
    	get_online_cpus();
    
    	for_each_online_cpu(cpu)
    		init_cpu(cpu);
    
    	register_cpu_notifier(&foobar_cpu_notifier);
    
    	put_online_cpus();
    
    This is wrong, since it is prone to ABBA deadlocks involving the
    cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
    with CPU hotplug operations).
    
    Interestingly, the raid5 code can actually prevent double initialization and
    hence can use the following simplified form of callback registration:
    
    	register_cpu_notifier(&foobar_cpu_notifier);
    
    	get_online_cpus();
    
    	for_each_online_cpu(cpu)
    		init_cpu(cpu);
    
    	put_online_cpus();
    
    A hotplug operation that occurs between registering the notifier and calling
    get_online_cpus(), won't disrupt anything, because the code takes care to
    perform the memory allocations only once.
    
    So reorganize the code in raid5 this way to fix the deadlock with callback
    registration.
    
    Cc: linux-raid@vger.kernel.org
    Fixes: 36d1c6476be51101778882897b315bd928c8c7b5
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    [Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the
    free_scratch_buffer() helper to condense code further and wrote the changelog.]
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5b56dda4701918b565764e47a60aa252964411c
Author: Jens Axboe <axboe@fb.com>
Date:   Wed Feb 12 09:34:01 2014 -0700

    block: add cond_resched() to potentially long running ioctl discard loop
    
    commit c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream.
    
    When mkfs issues a full device discard and the device only
    supports discards of a smallish size, we can loop in
    blkdev_issue_discard() for a long time. If preempt isn't enabled,
    this can turn into a softlock situation and the kernel will
    start complaining.
    
    Add an explicit cond_resched() at the end of the loop to avoid
    that.
    
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b5b0899755964724d1a2cccd472c8051186edc15
Author: Raymond Wanyoike <raymond.wanyoike@gmail.com>
Date:   Sun Feb 9 11:59:46 2014 +0300

    usb: option: blacklist ZTE MF667 net interface
    
    commit 3635c7e2d59f7861afa6fa5e87e2a58860ff514d upstream.
    
    Interface #5 of 19d2:1270 is a net interface which has been submitted to the
    qmi_wwan driver so consequently remove it from the option driver.
    
    Signed-off-by: Raymond Wanyoike <raymond.wanyoike@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13f09b941bc8cfb1a1355a26c999bad59af4db12
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Feb 11 19:52:06 2014 +0200

    drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB
    
    commit f66fab8e1cd6b3127ba4c5c0d11539fbe1de1e36 upstream.
    
    According to BSpec the entire MI_DISPLAY_FLIP packet must be contained
    in a single cacheline. Make sure that happens.
    
    v2: Use intel_ring_begin_cacheline_safe()
    v3: Use intel_ring_cacheline_align() (Chris)
    
    Cc: Bjoern C <lkml@call-home.ch>
    Cc: Alexandru DAMIAN <alexandru.damian@intel.com>
    Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a1d6c3c8ce2022462ca9b56fde45ffb69821690
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Feb 11 19:52:05 2014 +0200

    drm/i915: Add intel_ring_cachline_align()
    
    commit 753b1ad4a281b0663329409d410243e91825c323 upstream.
    
    intel_ring_cachline_align() emits MI_NOOPs until the ring tail is
    aligned to a cacheline boundary.
    
    Cc: Bjoern C <lkml@call-home.ch>
    Cc: Alexandru DAMIAN <alexandru.damian@intel.com>
    Cc: Enrico Tagliavini <enrico.tagliavini@gmail.com>
    Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b52b81c22aca6ce4a38015ec54911ede7ab563bc
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Tue Feb 11 13:38:54 2014 -0500

    ring-buffer: Fix first commit on sub-buffer having non-zero delta
    
    commit d651aa1d68a2f0a7ee65697b04c6a92f8c0a12f2 upstream.
    
    Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on
    that page use a 27 bit delta against that timestamp in order to save on
    bits written to the ring buffer. If the time between events is larger than
    what the 27 bits can hold, a "time extend" event is added to hold the
    entire 64 bit timestamp again and the events after that hold a delta from
    that timestamp.
    
    As a "time extend" is always paired with an event, it is logical to just
    allocate the event with the time extend, to make things a bit more efficient.
    
    Unfortunately, when the pairing code was written, it removed the "delta = 0"
    from the first commit on a page, causing the events on the page to be
    slightly skewed.
    
    Fixes: 69d1b839f7ee "ring-buffer: Bind time extend and data events together"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3f32b4fd37f291cf5807f0b8b281bf54d6006a60
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Mon Feb 10 13:54:02 2014 +0000

    xen: install xen/gntdev.h and xen/gntalloc.h
    
    commit 564eb714f5f09ac733c26860d5f0831f213fbdf1 upstream.
    
    xen/gntdev.h and xen/gntalloc.h both provide userspace ABIs so they
    should be installed.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [bwh: Backported to 3.2: no renaming is required]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b74f4e816a27789a083db94819df658d100156f
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Tue Feb 11 09:15:54 2014 -0500

    SUNRPC: Fix races in xs_nospace()
    
    commit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream.
    
    When a send failure occurs due to the socket being out of buffer space,
    we call xs_nospace() in order to have the RPC task wait until the
    socket has drained enough to make it worth while trying again.
    The current patch fixes a race in which the socket is drained before
    we get round to setting up the machinery in xs_nospace(), and which
    is reported to cause hangs.
    
    Link: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown
    Fixes: a9a6b52ee1ba (SUNRPC: Don't start the retransmission timer...)
    Reported-by: Neil Brown <neilb@suse.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 24f600a42821551c33114b7598f2a6b7fc1894b6
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Feb 10 14:25:41 2014 -0800

    fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem
    
    commit 96c7a2ff21501691587e1ae969b83cbec8b78e08 upstream.
    
    Recently due to a spike in connections per second memcached on 3
    separate boxes triggered the OOM killer from accept.  At the time the
    OOM killer was triggered there was 4GB out of 36GB free in zone 1.  The
    problem was that alloc_fdtable was allocating an order 3 page (32KiB) to
    hold a bitmap, and there was sufficient fragmentation that the largest
    page available was 8KiB.
    
    I find the logic that PAGE_ALLOC_COSTLY_ORDER can't fail pretty dubious
    but I do agree that order 3 allocations are very likely to succeed.
    
    There are always pathologies where order > 0 allocations can fail when
    there are copious amounts of free memory available.  Using the pigeon
    hole principle it is easy to show that it requires 1 page more than 50%
    of the pages being free to guarantee an order 1 (8KiB) allocation will
    succeed, 1 page more than 75% of the pages being free to guarantee an
    order 2 (16KiB) allocation will succeed and 1 page more than 87.5% of
    the pages being free to guarantee an order 3 allocate will succeed.
    
    A server churning memory with a lot of small requests and replies like
    memcached is a common case that if anything can will skew the odds
    against large pages being available.
    
    Therefore let's not give external applications a practical way to kill
    linux server applications, and specify __GFP_NORETRY to the kmalloc in
    alloc_fdmem.  Unless I am misreading the code and by the time the code
    reaches should_alloc_retry in __alloc_pages_slowpath (where
    __GFP_NORETRY becomes signification).  We have already tried everything
    reasonable to allocate a page and the only thing left to do is wait.  So
    not waiting and falling back to vmalloc immediately seems like the
    reasonable thing to do even if there wasn't a chance of triggering the
    OOM killer.
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Cong Wang <cwang@twopensource.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8c8e77aa65fd685e09804e7a6709c82baa3648d1
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Feb 7 19:12:32 2014 +0100

    ARM: 7955/1: spinlock: ensure we have a compiler barrier before sev
    
    commit 7c8746a9eb287642deaad0e7c2cdf482dce5e4be upstream.
    
    When unlocking a spinlock, we require the following, strictly ordered
    sequence of events:
    
    	<barrier>	/* dmb */
    	<unlock>
    	<barrier>	/* dsb */
    	<sev>
    
    Whilst the code does indeed reflect this in terms of the architecture,
    the final <barrier> + <sev> have been contracted into a single inline
    asm without a "memory" clobber, therefore the compiler is at liberty to
    reorder the unlock to the end of the above sequence. In such a case,
    a waiting CPU may be woken up before the lock has been unlocked, leading
    to extremely poor performance.
    
    This patch reworks the dsb_sev() function to make use of the dsb()
    macro and ensure ordering against the unlock.
    
    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [bwh: Backported to 3.2: 'ishst' variant is not used here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b768f21422c7ba677c3a2e594881fd412984e665
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Feb 7 19:12:20 2014 +0100

    ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling MMU
    
    commit bae0ca2bc550d1ec6a118fb8f2696f18c4da3d8e upstream.
    
    During __v{6,7}_setup, we invalidate the TLBs since we are about to
    enable the MMU on return to head.S. Unfortunately, without a subsequent
    dsb instruction, the invalidation is not guaranteed to have completed by
    the time we write to the sctlr, potentially exposing us to junk/stale
    translations cached in the TLB.
    
    This patch reworks the init functions so that the dsb used to ensure
    completion of cache/predictor maintenance is also used to ensure
    completion of the TLB invalidation.
    
    Reported-by: Albin Tonnerre <Albin.Tonnerre@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1199a29a07b529adedb1623dd2a6e17c33c763f2
Author: Jan Moskyto Matejka <mq@suse.cz>
Date:   Fri Feb 7 19:15:11 2014 +0100

    Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
    
    commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc upstream.
    
    Commit afe2dab4f6 ("USB: add hex/bcd detection to usb modalias generation")
    changed the routine that generates alias ranges. Before that change, only
    digits 0-9 were supported; the commit tried to fix the case when the range
    includes higher values than 0x9.
    
    Unfortunately, the commit didn't fix the case when the range includes both
    0x9 and 0xA, meaning that the final range must look like [x-9A-y] where
    x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced.
    
    Modprobe doesn't complain as it sees no difference between no-match and
    bad-pattern results of fnmatch().
    
    Fixing this simple bug to fix the aliases.
    Also changing the hardcoded beginning of the range to uppercase as all the
    other letters are also uppercase in the device version numbers.
    
    Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK.
    
    Signed-off-by: Jan Moskyto Matejka <mq@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93fb7adb880cf960485cfe4c599904e959890be9
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Tue Feb 4 18:53:56 2014 +0000

    xen-blkfront: handle backend CLOSED without CLOSING
    
    commit 3661371701e714f0cea4120f6a365340858fb4e4 upstream.
    
    Backend drivers shouldn't transistion to CLOSED unless the frontend is
    CLOSED.  If a backend does transition to CLOSED too soon then the
    frontend may not see the CLOSING state and will not properly shutdown.
    
    So, treat an unexpected backend CLOSED state the same as CLOSING.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 78f94be0386e7b4d2a871950038b66242ff662db
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Wed Feb 5 14:59:53 2014 -0700

    staging: comedi: adv_pci1710: fix analog output readback value
    
    commit 1e85c1ea1ff2a60659e790ef8ec76c7339445841 upstream.
    
    The last value written to a analog output channel is cached in the
    private data of this driver for readback.
    
    Currently, the wrong value is cached in the (*insn_write) functions.
    The current code stores the data[n] value for readback afer the loop
    has written all the values. At this time 'n' points past the end of
    the data array.
    
    Fix the functions by using a local variable to hold the data being
    written to the analog output channel. This variable is then used
    after the loop is complete to store the readback value. The current
    value is retrieved before the loop in case no values are actually
    written..
    
    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7fd7398a897d649086c8f86626ed1d082413a6a0
Author: Lars Poeschel <poeschel@lemonage.de>
Date:   Tue Jan 7 13:34:37 2014 +0100

    tty: n_gsm: Fix for modems with brk in modem status control
    
    commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.
    
    3GPP TS 07.10 states in section 5.4.6.3.7:
    "The length byte contains the value 2 or 3 ... depending on the break
    signal." The break byte is optional and if it is sent, the length is
    3. In fact the driver was not able to work with modems that send this
    break byte in their modem status control message. If the modem just
    sends the break byte if it is really set, then weird things might
    happen.
    The code for deconding the modem status to the internal linux
    presentation in gsm_process_modem has already a big comment about
    this 2 or 3 byte length thing and it is already able to decode the
    brk, but the code calling the gsm_process_modem function in
    gsm_control_modem does not encode it and hand it over the right way.
    This patch fixes this.
    Without this fix if the modem sends the brk byte in it's modem status
    control message the driver will hang when opening a muxed channel.
    
    Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f934bf515d57d597ea1b6b001e80dcda8d369cf7
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Tue Feb 4 23:23:12 2014 +0100

    raw: test against runtime value of max_raw_minors
    
    commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream.
    
    bind_get() checks the device number it is called with. It uses
    MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile
    time while the actual number of raw devices can be set at runtime. This
    means the test can either be too strict or too lenient. And if the test
    ends up being too lenient bind_get() might try to access memory beyond
    what was allocated for "raw_devices".
    
    So check against the runtime value (max_raw_minors) in this function.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e17acbd7b5831a07b7582a1cb1cddb38ea12b2f3
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Thu Jan 16 11:59:58 2014 -0800

    Drivers: hv: vmbus: Don't timeout during the initial connection with host
    
    commit 269f979467cf49f2ea8132316c1f00f8c9678f7c upstream.
    
    When the guest attempts to connect with the host when there may already be a
    connection with the host (as would be the case during the kdump/kexec path),
    it is difficult to guarantee timely response from the host. Starting with
    WS2012 R2, the host supports this ability to re-connect with the host
    (explicitly to support kexec). Prior to responding to the guest, the host
    needs to ensure that device states based on the previous connection to
    the host have been properly torn down. This may introduce unbounded delays.
    To deal with this issue, don't do a timed wait during the initial connect
    with the host.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ede028efb3747019a6af0d00536f147d27bfae4d
Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date:   Thu Feb 6 12:04:28 2014 -0800

    mm: __set_page_dirty uses spin_lock_irqsave instead of spin_lock_irq
    
    commit 227d53b397a32a7614667b3ecaf1d89902fb6c12 upstream.
    
    To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
    During aio buffer migration, we have a possibility to see the following
    call stack.
    
    aio_migratepage  [disable interrupt]
      migrate_page_copy
        clear_page_dirty_for_io
          set_page_dirty
            __set_page_dirty_buffers
              __set_page_dirty
                spin_lock_irq
    
    This mean, current aio migration is a deadlockable.  spin_lock_irqsave
    is a safer alternative and we should use it.
    
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reported-by: David Rientjes rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e6a9c694dfa497099665ef93cbd6aaf72df3d150
Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date:   Thu Feb 6 12:04:24 2014 -0800

    mm: __set_page_dirty_nobuffers() uses spin_lock_irqsave() instead of spin_lock_irq()
    
    commit a85d9df1ea1d23682a0ed1e100e6965006595d06 upstream.
    
    During aio stress test, we observed the following lockdep warning.  This
    mean AIO+numa_balancing is currently deadlockable.
    
    The problem is, aio_migratepage disable interrupt, but
    __set_page_dirty_nobuffers unintentionally enable it again.
    
    Generally, all helper function should use spin_lock_irqsave() instead of
    spin_lock_irq() because they don't know caller at all.
    
       other info that might help us debug this:
        Possible unsafe locking scenario:
    
              CPU0
              ----
         lock(&(&ctx->completion_lock)->rlock);
         <Interrupt>
           lock(&(&ctx->completion_lock)->rlock);
    
        *** DEADLOCK ***
    
          dump_stack+0x19/0x1b
          print_usage_bug+0x1f7/0x208
          mark_lock+0x21d/0x2a0
          mark_held_locks+0xb9/0x140
          trace_hardirqs_on_caller+0x105/0x1d0
          trace_hardirqs_on+0xd/0x10
          _raw_spin_unlock_irq+0x2c/0x50
          __set_page_dirty_nobuffers+0x8c/0xf0
          migrate_page_copy+0x434/0x540
          aio_migratepage+0xb1/0x140
          move_to_new_page+0x7d/0x230
          migrate_pages+0x5e5/0x700
          migrate_misplaced_page+0xbc/0xf0
          do_numa_page+0x102/0x190
          handle_pte_fault+0x241/0x970
          handle_mm_fault+0x265/0x370
          __do_page_fault+0x172/0x5a0
          do_page_fault+0x1a/0x70
          page_fault+0x28/0x30
    
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <jweiner@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3b55f356eb75d91bcf583a98f6252029481303c
Author: Weijie Yang <weijie.yang@samsung.com>
Date:   Thu Feb 6 12:04:23 2014 -0800

    mm/swap: fix race on swap_info reuse between swapoff and swapon
    
    commit f893ab41e4dae2fe8991faf5d86d029068d1ef3a upstream.
    
    swapoff clear swap_info's SWP_USED flag prematurely and free its
    resources after that.  A concurrent swapon will reuse this swap_info
    while its previous resources are not cleared completely.
    
    These late freed resources are:
     - p->percpu_cluster
     - swap_cgroup_ctrl[type]
     - block_device setting
     - inode->i_flags &= ~S_SWAPFILE
    
    This patch clears the SWP_USED flag after all its resources are freed,
    so that swapon can reuse this swap_info by alloc_swap_info() safely.
    
    [akpm@linux-foundation.org: tidy up code comment]
    Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d2fc4a69dadefef65e38ebfb15b8e29d9a3a9206
Author: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Date:   Thu Feb 6 15:58:20 2014 +0100

    x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y
    
    commit 6583327c4dd55acbbf2a6f25e775b28b3abf9a42 upstream.
    
    Commit d61931d89b, "x86: Add optimized popcnt variants" introduced
    compile flag -fcall-saved-rdi for lib/hweight.c. When combined with
    options -fprofile-arcs and -O2, this flag causes gcc to generate
    broken constructor code. As a result, a 64 bit x86 kernel compiled
    with CONFIG_GCOV_PROFILE_ALL=y prints message "gcov: could not create
    file" and runs into sproadic BUGs during boot.
    
    The gcc people indicate that these kinds of problems are endemic when
    using ad hoc calling conventions.  It is therefore best to treat any
    file compiled with ad hoc calling conventions as an isolated
    environment and avoid things like profiling or coverage analysis,
    since those subsystems assume a "normal" calling conventions.
    
    This patch avoids the bug by excluding lib/hweight.o from coverage
    profiling.
    
    Reported-by: Meelis Roos <mroos@linux.ee>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/52F3A30C.7050205@linux.vnet.ibm.com
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2fc5a0290af97e1891fedd02961240e92f1619e2
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Jan 24 16:41:36 2014 -0500

    time: Fix overflow when HZ is smaller than 60
    
    commit 80d767d770fd9c697e434fd080c2db7b5c60c6dd upstream.
    
    When compiling for the IA-64 ski emulator, HZ is set to 32 because the
    emulation is slow and we don't want to waste too many cycles processing
    timers. Alpha also has an option to set HZ to 32.
    
    This causes integer underflow in
    kernel/time/jiffies.c:
    kernel/time/jiffies.c:66:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
      .mult  = NSEC_PER_JIFFY << JIFFIES_SHIFT, /* details above */
      ^
    
    This patch reduces the JIFFIES_SHIFT value to avoid the overflow.
    
    Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1401241639100.23871@file01.intranet.prod.int.rdu2.redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c7b18cdf1887e8ce91e04342cfd2d8fe1630be92
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Feb 1 00:16:23 2014 +0100

    mac80211: fix fragmentation code, particularly for encryption
    
    commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream.
    
    The "new" fragmentation code (since my rewrite almost 5 years ago)
    erroneously sets skb->len rather than using skb_trim() to adjust
    the length of the first fragment after copying out all the others.
    This leaves the skb tail pointer pointing to after where the data
    originally ended, and thus causes the encryption MIC to be written
    at that point, rather than where it belongs: immediately after the
    data.
    
    The impact of this is that if software encryption is done, then
     a) encryption doesn't work for the first fragment, the connection
        becomes unusable as the first fragment will never be properly
        verified at the receiver, the MIC is practically guaranteed to
        be wrong
     b) we leak up to 8 bytes of plaintext (!) of the packet out into
        the air
    
    This is only mitigated by the fact that many devices are capable
    of doing encryption in hardware, in which case this can't happen
    as the tail pointer is irrelevant in that case. Additionally,
    fragmentation is not used very frequently and would normally have
    to be configured manually.
    
    Fix this by using skb_trim() properly.
    
    Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c211cc680260ad8a5714e31d37e2c8be4e0d9c43
Author: Ulrich Hahn <uhahn@eanco.de>
Date:   Sun Feb 2 14:42:52 2014 +0100

    USB: ftdi_sio: add Tagsys RFID Reader IDs
    
    commit 76f24e3f39a1a94bab0d54e98899d64abcd9f69c upstream.
    
    Adding two more IDs to the ftdi_sio usb serial driver.
    It now connects Tagsys RFID readers.
    There might be more IDs out there for other Tagsys models.
    
    Signed-off-by: Ulrich Hahn <uhahn@eanco.de>
    Cc: Johan Hovold <johan@hovold.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e14777a011c7a49ed9f830e5f85654c9fe698538
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Thu Jan 30 11:26:59 2014 -0500

    SELinux: Fix kernel BUG on empty security contexts.
    
    commit 2172fa709ab32ca60e86179dc67d0857be8e2c98 upstream.
    
    Setting an empty security context (length=0) on a file will
    lead to incorrectly dereferencing the type and other fields
    of the security context structure, yielding a kernel BUG.
    As a zero-length security context is never valid, just reject
    all such security contexts whether coming from userspace
    via setxattr or coming from the filesystem upon a getxattr
    request by SELinux.
    
    Setting a security context value (empty or otherwise) unknown to
    SELinux in the first place is only possible for a root process
    (CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
    if the corresponding SELinux mac_admin permission is also granted
    to the domain by policy.  In Fedora policies, this is only allowed for
    specific domains such as livecd for setting down security contexts
    that are not defined in the build host policy.
    
    Reproducer:
    su
    setenforce 0
    touch foo
    setfattr -n security.selinux foo
    
    Caveat:
    Relabeling or removing foo after doing the above may not be possible
    without booting with SELinux disabled.  Any subsequent access to foo
    after doing the above will also trigger the BUG.
    
    BUG output from Matthew Thode:
    [  473.893141] ------------[ cut here ]------------
    [  473.962110] kernel BUG at security/selinux/ss/services.c:654!
    [  473.995314] invalid opcode: 0000 [#6] SMP
    [  474.027196] Modules linked in:
    [  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
    3.13.0-grsec #1
    [  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
    07/29/10
    [  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
    ffff8805f50cd488
    [  474.183707] RIP: 0010:[<ffffffff814681c7>]  [<ffffffff814681c7>]
    context_struct_compute_av+0xce/0x308
    [  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
    [  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
    0000000000000100
    [  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
    ffff8805e8aaa000
    [  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
    0000000000000006
    [  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
    0000000000000006
    [  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
    0000000000000000
    [  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
    knlGS:0000000000000000
    [  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
    00000000000207f0
    [  474.556058] Stack:
    [  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
    ffff8805f1190a40
    [  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
    ffff8805e8aac860
    [  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
    ffff8805c0ac3d94
    [  474.690461] Call Trace:
    [  474.723779]  [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
    [  474.778049]  [<ffffffff81468824>] security_compute_av+0xf4/0x20b
    [  474.811398]  [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
    [  474.843813]  [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
    [  474.875694]  [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
    [  474.907370]  [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
    [  474.938726]  [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
    [  474.970036]  [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
    [  475.000618]  [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
    [  475.030402]  [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
    [  475.061097]  [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
    [  475.094595]  [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
    [  475.148405]  [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
    [  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
    8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
    75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
    [  475.255884] RIP  [<ffffffff814681c7>]
    context_struct_compute_av+0xce/0x308
    [  475.296120]  RSP <ffff8805c0ac3c38>
    [  475.328734] ---[ end trace f076482e9d754adc ]---
    
    Reported-by:  Matthew Thode <mthode@mthode.org>
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 99ea864bc2c999bab93729d83f7eef40c2a95754
Author: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Date:   Mon Feb 3 13:31:03 2014 -0200

    of: fix PCI bus match for PCIe slots
    
    commit 14e2abb732e485ee57d9d5b2cb8884652238e5c1 upstream.
    
    On IBM pseries systems the device_type device-tree property of a PCIe
    bridge contains the string "pciex". The of_bus_pci_match() function was
    looking only for "pci" on this property, so in such cases the bus
    matching code was falling back to the default bus, causing problems on
    functions that should be using "assigned-addresses" for region address
    translation. This patch fixes the problem by also looking for "pciex" on
    the PCI bus match function.
    
    v2: added comment
    
    Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
    Acked-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 57200657f1cd8d9d579ee4b110c7eeada3e61d0d
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Jul 3 16:01:10 2013 +1000

    of: Fix address decoding on Bimini and js2x machines
    
    commit 6dd18e4684f3d188277bbbc27545248487472108 upstream.
    
     Commit:
    
      e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
      of/address: Handle #address-cells > 2 specially
    
    broke real time clock access on Bimini, js2x, and similar powerpc
    machines using the "maple" platform. That code was indirectly relying
    on the old (broken) behaviour of the translation for the hypertransport
    to ISA bridge.
    
    This fixes it by treating hypertransport as a PCI bus
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9735862809c0aad5cb427a13868ce1a1997871fb
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 3 09:56:13 2014 +0100

    ALSA: hda/realtek - Avoid invalid COEFs for ALC271X
    
    commit d3c56568f43807135f2c2a09582a69f809f0d8b7 upstream.
    
    We've seen often problems after suspend/resume on Acer Aspire One
    AO725 with ALC271X codec as reported in kernel bugzilla, and it turned
    out that some COEFs doesn't work and triggers the codec communication
    stall.
    
    Since these magic COEF setups are specific to ALC269VB for some PLL
    configurations, the machine works even without these manual
    adjustment.  So, let's simply avoid applying them for ALC271X.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: return 0]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fecfa5d27e1a8f833d2d4d4705946c7aaa6b4e07
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jan 30 10:43:22 2014 -0500

    usb-storage: enable multi-LUN scanning when needed
    
    commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream.
    
    People sometimes create their own custom-configured kernels and forget
    to enable CONFIG_SCSI_MULTI_LUN.  This causes problems when they plug
    in a USB storage device (such as a card reader) with more than one
    LUN.
    
    Fortunately, we can tell fairly easily when a storage device claims to
    have more than one LUN.  When that happens, this patch asks the SCSI
    layer to probe all the LUNs automatically, regardless of the config
    setting.
    
    The patch also updates the Kconfig help text for usb-storage,
    explaining that CONFIG_SCSI_MULTI_LUN may be necessary.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Thomas Raschbacher <lordvan@lordvan.com>
    CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    CC: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - slave_alloc() already has a us_data pointer]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef5bc9a475f12442ace9b7cc9f22d2a7fc928fdc
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Jan 21 10:38:45 2014 -0500

    usb-storage: add unusual-devs entry for BlackBerry 9000
    
    commit c5637e5119c43452a00e27c274356b072263ecbb upstream.
    
    This patch adds an unusual-devs entry for the BlackBerry 9000.  This
    fixes Bugzilla #22442.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
    Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f30ec1cb46ac768d74adaac2cd2508d7b243b3dc
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jan 30 10:20:29 2014 -0500

    usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB
    
    commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream.
    
    The Cypress ATACB unusual-devs entry for the Super Top SATA bridge
    causes problems.  Although it was originally reported only for
    bcdDevice = 0x160, its range was much larger.  This resulted in a bug
    report for bcdDevice 0x220, so the range was capped at 0x219.  Now
    Milan reports errors with bcdDevice 0x150.
    
    Therefore this patch restricts the range to just 0x160.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6055d4145bb6839ef871ae49586138544a6d1647
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Jan 14 18:56:54 2014 +0100

    usb: ftdi_sio: add Mindstorms EV3 console adapter
    
    commit 67847baee056892dc35efb9c3fd05ae7f075588c upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3af9cddbeb22bf36bb40029c8d954b5c77919d21
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Tue Feb 4 08:37:53 2014 +0530

    ath9k: Do not support PowerSave by default
    
    commit 8298383c2cd5a6d0639f1bb1781fba181bd20154 upstream.
    
    Even though we make sure PowerSave is not enabled by default
    by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
    PS could be enabled by userspace based on various factors
    like battery usage etc. Since PS in ath9k is just broken
    and has been untested for years, remove support for it, but
    allow a user to explicitly enable it using a module parameter.
    
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3fca80e2025094e7791b6669d799285a0a69010
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Thu Jan 30 09:14:53 2014 +0100

    ath9k_htc: Do not support PowerSave by default
    
    commit 6bca610d97b6139a1d7598b8009da9d339daa50f upstream.
    
    It is a copy/paste of patch provided by Sujith for ath9k.
    
    "Even though we make sure PowerSave is not enabled by default
    by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
    PS could be enabled by userspace based on various factors
    like battery usage etc. Since PS in ath9k is just broken
    and has been untested for years, remove support for it, but
    allow a user to explicitly enable it using a module parameter."
    
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41d1e615ecd7ef201ad332bba6fc6609f1bcb063
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Thu Jan 30 16:14:02 2014 +0100

    s390/dump: Fix dump memory detection
    
    commit d7736ff5be31edaa4fe5ab62810c64529a24b149 upstream.
    
    Dumps created by kdump or zfcpdump can contain invalid memory holes when
    dumping z/VM systems that have memory pressure.
    
    For example:
    
       # zgetdump -i /proc/vmcore.
       Memory map:
       0000000000000000 - 0000000000bfffff (12 MB)
       0000000000e00000 - 00000000014fffff (7 MB)
       000000000bd00000 - 00000000f3bfffff (3711 MB)
    
    The memory detection function find_memory_chunks() issues tprot to
    find valid memory chunks. In case of CMM it can happen that pages are
    marked as unstable via set_page_unstable() in arch_free_page().
    If z/VM has released that pages, tprot returns -EFAULT and indicates
    a memory hole.
    
    So fix this and switch off CMM in case of kdump or zfcpdump.
    
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c4d57f53339dc2e9ad9999bc87cf3d2fed1f5b5d
Author: Dave Jones <davej@fedoraproject.org>
Date:   Thu Jan 30 00:17:09 2014 -0300

    mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset
    
    commit 13e1b87c986100169b0695aeb26970943665eda9 upstream.
    
    Fix the following build error:
    
    drivers/media/usb/dvb-usb-v2/
    mxl111sf-tuner.h:72:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘struct’
             struct mxl111sf_tuner_config *cfg)
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ca839335f116548cb8f9cc4a0f4936b156309a01
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Feb 3 10:42:07 2014 -0500

    sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN
    
    commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.
    
    It's a bit odd to see a newer device showing mod15write; however, the
    reported behavior is highly consistent and other factors which could
    contribute seem to have been verified well enough.  Also, both
    sata_sil itself and the drive are fairly outdated at this point making
    the risk of this change fairly low.  It is possible, probably likely,
    that other drive models in the same family have the same problem;
    however, for now, let's just add the specific model which was tested.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: matson <lists-matsonpa@luxsci.me>
    References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa750e51dece6a5993dc8584ba92d5c8e4711d2b
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Thu Jan 30 14:32:45 2014 +0100

    power: max17040: Fix NULL pointer dereference when there is no platform_data
    
    commit ac323d8d807060f7c95a685a9fe861e7b6300993 upstream.
    
    Fix NULL pointer dereference of "chip->pdata" if platform_data was not
    supplied to the driver.
    
    The driver during probe stored the pointer to the platform_data:
    	chip->pdata = client->dev.platform_data;
    Later it was dereferenced in max17040_get_online() and
    max17040_get_status().
    
    If platform_data was not supplied, the NULL pointer exception would
    happen:
    
    [    6.626094] Unable to handle kernel  of a at virtual address 00000000
    [    6.628557] pgd = c0004000
    [    6.632868] [00000000] *pgd=66262564
    [    6.634636] Unable to handle kernel paging request at virtual address e6262000
    [    6.642014] pgd = de468000
    [    6.644700] [e6262000] *pgd=00000000
    [    6.648265] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    [    6.653552] Modules linked in:
    [    6.656598] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 3.10.14-02717-gc58b4b4 #505
    [    6.664334] Workqueue: events max17040_work
    [    6.668488] task: dfa11b80 ti: df9f6000 task.ti: df9f6000
    [    6.673873] PC is at show_pte+0x80/0xb8
    [    6.677687] LR is at show_pte+0x3c/0xb8
    [    6.681503] pc : [<c001b7b8>]    lr : [<c001b774>]    psr: 600f0113
    [    6.681503] sp : df9f7d58  ip : 600f0113  fp : 00000009
    [    6.692965] r10: 00000000  r9 : 00000000  r8 : dfa11b80
    [    6.698171] r7 : df9f7ea0  r6 : e6262000  r5 : 00000000  r4 : 00000000
    [    6.704680] r3 : 00000000  r2 : e6262000  r1 : 600f0193  r0 : c05b3750
    [    6.711194] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    [    6.718485] Control: 10c53c7d  Table: 5e46806a  DAC: 00000015
    [    6.724218] Process kworker/0:1 (pid: 31, stack limit = 0xdf9f6238)
    [    6.730465] Stack: (0xdf9f7d58 to 0xdf9f8000)
    [    6.914325] [<c001b7b8>] (show_pte+0x80/0xb8) from [<c047107c>] (__do_kernel_fault.part.9+0x44/0x74)
    [    6.923425] [<c047107c>] (__do_kernel_fault.part.9+0x44/0x74) from [<c001bb7c>] (do_page_fault+0x2c4/0x360)
    [    6.933144] [<c001bb7c>] (do_page_fault+0x2c4/0x360) from [<c0008400>] (do_DataAbort+0x34/0x9c)
    [    6.941825] [<c0008400>] (do_DataAbort+0x34/0x9c) from [<c000e5d8>] (__dabt_svc+0x38/0x60)
    [    6.950058] Exception stack(0xdf9f7ea0 to 0xdf9f7ee8)
    [    6.955099] 7ea0: df0c1790 00000000 00000002 00000000 df0c1794 df0c1790 df0c1790 00000042
    [    6.963271] 7ec0: df0c1794 00000001 00000000 00000009 00000000 df9f7ee8 c0306268 c0306270
    [    6.971419] 7ee0: a00f0113 ffffffff
    [    6.974902] [<c000e5d8>] (__dabt_svc+0x38/0x60) from [<c0306270>] (max17040_work+0x8c/0x144)
    [    6.983317] [<c0306270>] (max17040_work+0x8c/0x144) from [<c003f364>] (process_one_work+0x138/0x440)
    [    6.992429] [<c003f364>] (process_one_work+0x138/0x440) from [<c003fa64>] (worker_thread+0x134/0x3b8)
    [    7.001628] [<c003fa64>] (worker_thread+0x134/0x3b8) from [<c00454bc>] (kthread+0xa4/0xb0)
    [    7.009875] [<c00454bc>] (kthread+0xa4/0xb0) from [<c000eb28>] (ret_from_fork+0x14/0x2c)
    [    7.017943] Code: e1a03005 e2422480 e0826104 e59f002c (e7922104)
    [    7.024017] ---[ end trace 73bc7006b9cc5c79 ]---
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Fixes: c6f4a42de60b981dd210de01cd3e575835e3158e
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b93b90ff7c50288d602108ae1a09673df3f799a8
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jan 22 23:04:33 2014 -0500

    alpha: fix broken network checksum
    
    commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream.
    
    The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 breaks networking on
    alpha (there is a follow-up fix 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6,
    but networking is still broken even with the second patch).
    
    The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 makes
    csum_partial_copy_from_user check the pointer with access_ok. However,
    csum_partial_copy_from_user is called also from csum_partial_copy_nocheck
    and csum_partial_copy_nocheck is called on kernel pointers and it is
    supposed not to check pointer validity.
    
    This bug results in ssh session hangs if the system is loaded and bulk
    data are printed to ssh terminal.
    
    This patch fixes csum_partial_copy_nocheck to call set_fs(KERNEL_DS), so
    that access_ok in csum_partial_copy_from_user accepts kernel-space
    addresses.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e86e416d709499082625b6b8d3991813255c3779
Author: Denis V. Lunev <den@openvz.org>
Date:   Thu Jan 30 15:20:30 2014 +0400

    ata: enable quirk from jmicron JMB350 for JMB394
    
    commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.
    
    Without the patch the kernel generates the following error.
    
     ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
     ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
     ata11.15: PMP revalidation failed (errno=-19)
     ata11.15: failed to recover PMP after 5 tries, giving up
    
    This patch helps to bypass this error and the device becomes
    functional.
    
    Signed-off-by: Denis V. Lunev <den@openvz.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: <linux-ide@vger.kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41cf82c2b1e6a027d487c1f92dc3a0e811e1529a
Author: David Rientjes <rientjes@google.com>
Date:   Thu Jan 30 15:46:11 2014 -0800

    mm, oom: base root bonus on current usage
    
    commit 778c14affaf94a9e4953179d3e13a544ccce7707 upstream.
    
    A 3% of system memory bonus is sometimes too excessive in comparison to
    other processes.
    
    With commit a63d83f427fb ("oom: badness heuristic rewrite"), the OOM
    killer tries to avoid killing privileged tasks by subtracting 3% of
    overall memory (system or cgroup) from their per-task consumption.  But
    as a result, all root tasks that consume less than 3% of overall memory
    are considered equal, and so it only takes 33+ privileged tasks pushing
    the system out of memory for the OOM killer to do something stupid and
    kill dhclient or other root-owned processes.  For example, on a 32G
    machine it can't tell the difference between the 1M agetty and the 10G
    fork bomb member.
    
    The changelog describes this 3% boost as the equivalent to the global
    overcommit limit being 3% higher for privileged tasks, but this is not
    the same as discounting 3% of overall memory from _every privileged task
    individually_ during OOM selection.
    
    Replace the 3% of system memory bonus with a 3% of current memory usage
    bonus.
    
    By giving root tasks a bonus that is proportional to their actual size,
    they remain comparable even when relatively small.  In the example
    above, the OOM killer will discount the 1M agetty's 256 badness points
    down to 179, and the 10G fork bomb's 262144 points down to 183500 points
    and make the right choice, instead of discounting both to 0 and killing
    agetty because it's first in the task list.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Reported-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: existing code changes 'points' directly rather
     than using 'adj' variable]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60745e70f4b4725a1ae9387af914de0d25470491
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Wed Jan 22 13:01:33 2014 +0100

    crypto: s390 - fix des and des3_ede ctr concurrency issue
    
    commit ee97dc7db4cbda33e4241c2d85b42d1835bc8a35 upstream.
    
    In s390 des and 3des ctr mode there is one preallocated page
    used to speed up the en/decryption. This page is not protected
    against concurrent usage and thus there is a potential of data
    corruption with multiple threads.
    
    The fix introduces locking/unlocking the ctr page and a slower
    fallback solution at concurrency situations.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 33b121eb313609f3d8338eeabbc35c91a185771a
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Wed Jan 22 13:00:04 2014 +0100

    crypto: s390 - fix des and des3_ede cbc concurrency issue
    
    commit adc3fcf1552b6e406d172fd9690bbd1395053d13 upstream.
    
    In s390 des and des3_ede cbc mode the iv value is not protected
    against concurrency access and modifications from another running
    en/decrypt operation which is using the very same tfm struct
    instance. This fix copies the iv to the local stack before
    the crypto operation and stores the value back when done.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc211c9a572bba86c7d37c390c6fb3a9ff052f33
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Thu Jan 16 16:01:11 2014 +0100

    crypto: s390 - fix concurrency issue in aes-ctr mode
    
    commit 0519e9ad89e5cd6e6b08398f57c6a71d9580564c upstream.
    
    The aes-ctr mode uses one preallocated page without any concurrency
    protection. When multiple threads run aes-ctr encryption or decryption
    this can lead to data corruption.
    
    The patch introduces locking for the page and a fallback solution with
    slower en/decryption performance in concurrency situations.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 501ec62ed39a7232827d0c698c375d5294bda1ba
Author: Jan Glauber <jang@linux.vnet.ibm.com>
Date:   Fri Oct 26 15:06:12 2012 +0200

    s390/crypto: Don't panic after crypto instruction failures
    
    commit 36eb2caa7bace31b7868a57f77cb148e58d1c9f9 upstream.
    
    Remove the BUG_ON's that check for failure or incomplete
    results of the s390 hardware crypto instructions.
    Rather report the errors as -EIO to the crypto layer.
    
    Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6b1246d93e7af2d92e3652d96299fd2224c75ef7
Author: Andy Grover <agrover@redhat.com>
Date:   Fri Jan 24 16:18:54 2014 -0800

    target/iscsi: Fix network portal creation race
    
    commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream.
    
    When creating network portals rapidly, such as when restoring a
    configuration, LIO's code to reuse existing portals can return a false
    negative if the thread hasn't run yet and set np_thread_state to
    ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack
    when attempting to bind to the same address/port.
    
    This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list,
    so even if the thread hasn't run yet, iscsit_get_np will return the
    existing np.
    
    Also, convert np_lock -> np_mutex + hold across adding new net portal
    to g_np_list to prevent a race where two threads may attempt to create
    the same network portal, resulting in one of them failing.
    
    (nab: Add missing mutex_unlocks in iscsit_add_np failure paths)
    (DanC: Fix incorrect spin_unlock -> spin_unlock_bh)
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 64006c84cde2386dee613ebc729aa9463931c789
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jan 29 16:16:39 2014 +0300

    KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()
    
    commit aac5c4226e7136c331ed384c25d5560204da10a0 upstream.
    
    If kvm_io_bus_register_dev() fails then it returns success but it should
    return an error code.
    
    I also did a little cleanup like removing an impossible NULL test.
    
    Fixes: 2b3c246a682c ('KVM: Make coalesced mmio use a device per zone')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d4853d023a590181018241c960b1f25e1fe8b96
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 27 18:29:35 2014 -0500

    drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
    
    commit 6802d4bad83f50081b2788698570218aaff8d10e upstream.
    
    The BlankCrtc table in some DCE8 boards has some
    logic shortcuts for the vbios when this bit is set.
    Clear it for driver use.
    
    v2: fix typo
    
    Bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=73420
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5da1d4795ac0f31770429557c3d6003fe5c7641c
Author: Chris Mason <clm@fb.com>
Date:   Thu Jan 9 17:28:00 2014 -0800

    Btrfs: setup inode location during btrfs_init_inode_locked
    
    commit 90d3e592e99b8e374ead2b45148abf506493a959 upstream.
    
    We have a race during inode init because the BTRFS_I(inode)->location is setup
    after the inode hash table lock is dropped.  btrfs_find_actor uses the location
    field, so our search might not find an existing inode in the hash table if we
    race with the inode init code.
    
    This commit changes things to setup the location field sooner.  Also the find actor now
    uses only the location objectid to match inodes.  For inode hashing, we just
    need a unique and stable test, it doesn't have to reflect the inode numbers we
    show to userland.
    
    Signed-off-by: Chris Mason <clm@fb.com>
    [bwh: Backported to 3.2:
     - No hashval in btrfs_iget_locked()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1d4b777fc535b6f1c44aee2f2c77ac236d7336c6
Author: Paul Mackerras <paulus@samba.org>
Date:   Sat Jan 18 21:14:47 2014 +1100

    powerpc: Make sure "cache" directory is removed when offlining cpu
    
    commit 91b973f90c1220d71923e7efe1e61f5329806380 upstream.
    
    The code in remove_cache_dir() is supposed to remove the "cache"
    subdirectory from the sysfs directory for a CPU when that CPU is
    being offlined.  It tries to do this by calling kobject_put() on
    the kobject for the subdirectory.  However, the subdirectory only
    gets removed once the last reference goes away, and the reference
    being put here may well not be the last reference.  That means
    that the "cache" subdirectory may still exist when the offlining
    operation has finished.  If the same CPU subsequently gets onlined,
    the code tries to add a new "cache" subdirectory.  If the old
    subdirectory has not yet been removed, we get a WARN_ON in the
    sysfs code, with stack trace, and an error message printed on the
    console.  Further, we ultimately end up with an online cpu with no
    "cache" subdirectory.
    
    This fixes it by doing an explicit kobject_del() at the point where
    we want the subdirectory to go away.  kobject_del() removes the sysfs
    directory even though the object still exists in memory.  The object
    will get freed at some point in the future.  A subsequent onlining
    operation can create a new sysfs directory, even if the old object
    still exists in memory, without causing any problems.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a0746611cff692af285e286f337dcc3bfac02253
Author: Mark Brown <broonie@linaro.org>
Date:   Mon Jan 27 00:32:14 2014 +0000

    ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API
    
    commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.
    
    There is currently no facility in ACPI to express the hookup of voltage
    regulators, the expectation is that the regulators that exist in the
    system will be handled transparently by firmware if they need software
    control at all. This means that if for some reason the regulator API is
    enabled on such a system it should assume that any supplies that devices
    need are provided by the system at all relevant times without any software
    intervention.
    
    Tell the regulator core to make this assumption by calling
    regulator_has_full_constraints(). Do this as soon as we know we are using
    ACPI so that the information is available to the regulator core as early
    as possible. This will cause the regulator core to pretend that there is
    an always on regulator supplying any supply that is requested but that has
    not otherwise been mapped which is the behaviour expected on a system with
    ACPI.
    
    Should the ability to specify regulators be added in future revisions of
    ACPI then once we have support for ACPI mappings in the kernel the same
    assumptions will apply. It is also likely that systems will default to a
    mode of operation which does not require any interpretation of these
    mappings in order to be compatible with existing operating system releases
    so it should remain safe to make these assumptions even if the mappings
    exist but are not supported by the kernel.
    
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 72b104380dd54cae2a283caae0d96d28012117a6
Author: David Sterba <dsterba@suse.cz>
Date:   Wed Jan 15 18:15:52 2014 +0100

    btrfs: restrict snapshotting to own subvolumes
    
    commit d024206133ce21936b3d5780359afc00247655b7 upstream.
    
    Currently, any user can snapshot any subvolume if the path is accessible and
    thus indirectly create and keep files he does not own under his direcotries.
    This is not possible with traditional directories.
    
    In security context, a user can snapshot root filesystem and pin any
    potentially buggy binaries, even if the updates are applied.
    
    All the snapshots are visible to the administrator, so it's possible to
    verify if there are suspicious snapshots.
    
    Another more practical problem is that any user can pin the space used
    by eg. root and cause ENOSPC.
    
    Original report:
    https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/484786
    
    Signed-off-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use the same cleanup code for success and error cases, as done
       upstream in commit ecd188159efa
       ('switch btrfs_ioctl_snap_create_transid() to fget_light()')]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ff4cfa53b56c70c657d446f26f669bf7d2ee9ec
Author: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Date:   Tue Jan 7 17:26:58 2014 +0800

    Btrfs: handle EAGAIN case properly in btrfs_drop_snapshot()
    
    commit 90515e7f5d7d24cbb2a4038a3f1b5cfa2921aa17 upstream.
    
    We may return early in btrfs_drop_snapshot(), we shouldn't
    call btrfs_std_err() for this case, fix it.
    
    Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dca0911e0166162f38926c19ae0fce3b3cf37f01
Author: Mihai Caraman <mihai.caraman@freescale.com>
Date:   Thu Jan 9 17:01:05 2014 +0200

    KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()
    
    commit 70713fe315ed14cd1bb07d1a7f33e973d136ae3d upstream.
    
    Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss().
    
    Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a1d1c11c3d74677c210fb1a2db4dbeb239dc6d49
Author: Shane Huang <shane.huang@amd.com>
Date:   Wed Jan 22 14:05:46 2014 -0800

    i2c: piix4: Add support for AMD ML and CZ SMBus changes
    
    commit 032f708bc4f6da868ec49dac48ddf3670d8035d3 upstream.
    
    The locations of SMBus register base address and enablement bit are changed
    from AMD ML, which need this patch to be supported.
    
    Signed-off-by: Shane Huang <shane.huang@amd.com>
    Reviewed-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    [bwh: Backported to 3.2:
     - Adjust context
     - Aux bus support is not included]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e4c0c19999194326f5e46bb4711cb1b7c859f156
Author: ZHAO Gang <gamerh2o@gmail.com>
Date:   Sat Jan 18 00:17:38 2014 +0800

    b43: fix the wrong assignment of status.freq in b43_rx()
    
    commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.
    
    Use the right function to update frequency value.
    
    If rx skb is probe response or beacon, the wrong frequency value can
    cause problem that bss info can't be updated when it should be.
    
    Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211
    and driver conversion")
    Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c99cf525de222205729192b47e2b859096abe03a
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Thu Nov 21 17:58:08 2013 +0200

    ore: Fix wrong math in allocation of per device BIO
    
    commit aad560b7f63b495f48a7232fd086c5913a676e6f upstream.
    
    At IO preparation we calculate the max pages at each device and
    allocate a BIO per device of that size. The calculation was wrong
    on some unaligned corner cases offset/length combination and would
    make prepare return with -ENOMEM. This would be bad for pnfs-objects
    that would in that case IO through MDS. And fatal for exofs were it
    would fail writes with EIO.
    
    Fix it by doing the proper math, that will work in all cases. (I
    ran a test with all possible offset/length combinations this time
    round).
    
    Also when reading we do not need to allocate for the parity units
    since we jump over them.
    
    Also lower the max_io_length to take into account the parity pages
    so not to allocate BIOs bigger than PAGE_SIZE
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17c9dc712c75ac71d18a222d3d5b2f9dad5867b4
Author: Ira Weiny <ira.weiny@intel.com>
Date:   Wed Dec 18 08:41:37 2013 -0800

    IB/qib: Fix QP check when looping back to/from QP1
    
    commit 6e0ea9e6cbcead7fa8c76e3e3b9de4a50c5131c5 upstream.
    
    The GSI QP type is compatible with and should be allowed to send data
    to/from any UD QP.  This was found when testing ibacm on the same node
    as an SA.
    
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c4047a30fc81715ae56e97f983fd684360fa216c
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Jan 22 19:36:57 2014 +0100

    fuse: fix pipe_buf_operations
    
    commit 28a625cbc2a14f17b83e47ef907b2658576a32aa upstream.
    
    Having this struct in module memory could Oops when if the module is
    unloaded while the buffer still persists in a pipe.
    
    Since sock_pipe_buf_ops is essentially the same as fuse_dev_pipe_buf_steal
    merge them into nosteal_pipe_buf_ops (this is the same as
    default_pipe_buf_ops except stealing the page from the buffer is not
    allowed).
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d43cc1a69f62fe2c261863fc8a8ed9acca57b45f
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Jan 21 15:48:18 2014 -0800

    intel-iommu: fix off-by-one in pagetable freeing
    
    commit 08336fd218e087cc4fcc458e6b6dcafe8702b098 upstream.
    
    dma_pte_free_level() has an off-by-one error when checking whether a pte
    is completely covered by a range.  Take for example the case of
    attempting to free pfn 0x0 - 0x1ff, ie.  512 entries covering the first
    2M superpage.
    
    The level_size() is 0x200 and we test:
    
      static void dma_pte_free_level(...
    	...
    
    	if (!(0 > 0 || 0x1ff < 0 + 0x200)) {
    		...
    	}
    
    Clearly the 2nd test is true, which means we fail to take the branch to
    clear and free the pagetable entry.  As a result, we're leaking
    pagetables and failing to install new pages over the range.
    
    This was found with a PCI device assigned to a QEMU guest using vfio-pci
    without a VGA device present.  The first 1M of guest address space is
    mapped with various combinations of 4K pages, but eventually the range
    is entirely freed and replaced with a 2M contiguous mapping.
    intel-iommu errors out with something like:
    
      ERROR: DMA PTE for vPFN 0x0 already set (to 5c2b8003 not 849c00083)
    
    In this case 5c2b8003 is the pointer to the previous leaf page that was
    neither freed nor cleared and 849c00083 is the superpage entry that
    we're trying to replace it with.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 55cea4b505db73cab5ff46ad47faa4e5ce13de60
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 13 12:32:44 2014 +0100

    hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
    
    commit b0ad4ff35d479a46a3b995a299db9aeb097acfce upstream.
    
    The DriveGuard chips on the new HP laptops are with a new PnP ID
    "HPQ6007".  It should be compatible with older chips.
    
    Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7bf56b6a9a77bab5f7fc8f870d348e8374f6e626
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 16 18:11:47 2014 -0500

    drm/radeon: set the full cache bit for fences on r7xx+
    
    commit d45b964a22cad962d3ede1eba8d24f5cee7b2a92 upstream.
    
    Needed to properly flush the read caches for fences.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/\bring\b/rdev/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 03ee9dc36ecb95b78f91ad111d9340ec37efe969
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 13 16:47:05 2014 -0500

    drm/radeon: disable ss on DP for DCE3.x
    
    commit d8e24525094200601236fa64a54cf73e3d682f2e upstream.
    
    Seems to cause problems with certain DP monitors.
    
    Bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=40699
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: s/radeon_crtc->//]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9ae63f0c5fe163f200e6517c0a3e0d8721145bf
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Tue Aug 20 17:20:14 2013 -0700

    turbostat: Use GCC's CPUID functions to support PIC
    
    commit 2b92865e648ce04a39fda4f903784a5d01ecb0dc upstream.
    
    turbostat uses inline assembly to call cpuid.  On 32-bit x86, on systems
    that have certain security features enabled by default that make -fPIC
    the default, this causes a build error:
    
    turbostat.c: In function ‘check_cpuid’:
    turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
      asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
      ^
    
    GCC provides a header cpuid.h, containing a __get_cpuid function that
    works with both PIC and non-PIC.  (On PIC, it saves and restores ebx
    around the cpuid instruction.)  Use that instead.
    
    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4fab53434e082b3835f5a89d5af15983c2be664d
Author: Aisheng Dong <b29396@freescale.com>
Date:   Mon Dec 23 19:13:04 2013 +0800

    mmc: sdhci: fix lockdep error in tuning routine
    
    commit 2b35bd83467df6f8284b9148d6f768148c3a5e5f upstream.
    
    The sdhci_execute_tuning routine gets lock separately by
    disable_irq(host->irq);
    spin_lock(&host->lock);
    It will cause the following lockdep error message since the &host->lock
    could also be got in irq context.
    Use spin_lock_irqsave/spin_unlock_restore instead to get rid of
    this error message.
    
    [ INFO: inconsistent lock state ]
    3.13.0-rc1+ #287 Not tainted
    ---------------------------------
    inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    kworker/u2:1/33 [HC0[0]:SC0[0]:HE1:SE1] takes:
     (&(&host->lock)->rlock){?.-...}, at: [<8045f7f4>] sdhci_execute_tuning+0x4c/0x710
    {IN-HARDIRQ-W} state was registered at:
      [<8005f030>] mark_lock+0x140/0x6ac
      [<80060760>] __lock_acquire+0xb30/0x1cbc
      [<800620d0>] lock_acquire+0x70/0x84
      [<8061d1c8>] _raw_spin_lock+0x30/0x40
      [<804605cc>] sdhci_irq+0x24/0xa68
      [<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
      [<8006b350>] handle_irq_event+0x44/0x64
      [<8006e50c>] handle_fasteoi_irq+0xa0/0x170
      [<8006a8f0>] generic_handle_irq+0x30/0x44
      [<8000f238>] handle_IRQ+0x54/0xbc
      [<8000864c>] gic_handle_irq+0x30/0x64
      [<80013024>] __irq_svc+0x44/0x5c
      [<80329bf4>] dev_vprintk_emit+0x50/0x58
      [<80329c24>] dev_printk_emit+0x28/0x30
      [<80329fec>] __dev_printk+0x4c/0x90
      [<8032a180>] dev_err+0x3c/0x48
      [<802dd4f0>] _regulator_get+0x158/0x1cc
      [<802dd5b4>] regulator_get_optional+0x18/0x1c
      [<80461df4>] sdhci_add_host+0x42c/0xbd8
      [<80464820>] sdhci_esdhc_imx_probe+0x378/0x67c
      [<8032ee88>] platform_drv_probe+0x20/0x50
      [<8032d48c>] driver_probe_device+0x118/0x234
      [<8032d690>] __driver_attach+0x9c/0xa0
      [<8032b89c>] bus_for_each_dev+0x68/0x9c
      [<8032cf44>] driver_attach+0x20/0x28
      [<8032cbc8>] bus_add_driver+0x148/0x1f4
      [<8032dce0>] driver_register+0x80/0x100
      [<8032ee54>] __platform_driver_register+0x50/0x64
      [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
      [<80008980>] do_one_initcall+0x108/0x16c
      [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
      [<80611b28>] kernel_init+0x10/0x120
      [<8000e9c8>] ret_from_fork+0x14/0x2c
    irq event stamp: 805
    hardirqs last  enabled at (805): [<8061d43c>] _raw_spin_unlock_irqrestore+0x38/0x4c
    hardirqs last disabled at (804): [<8061d2c8>] _raw_spin_lock_irqsave+0x24/0x54
    softirqs last  enabled at (570): [<8002b824>] __do_softirq+0x1c4/0x290
    softirqs last disabled at (561): [<8002bcf4>] irq_exit+0xb4/0x10c
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&host->lock)->rlock);
      <Interrupt>
        lock(&(&host->lock)->rlock);
    
     *** DEADLOCK ***
    
    2 locks held by kworker/u2:1/33:
     #0:  (kmmcd){.+.+..}, at: [<8003db18>] process_one_work+0x128/0x468
     #1:  ((&(&host->detect)->work)){+.+...}, at: [<8003db18>] process_one_work+0x128/0x468
    
    stack backtrace:
    CPU: 0 PID: 33 Comm: kworker/u2:1 Not tainted 3.13.0-rc1+ #287
    Workqueue: kmmcd mmc_rescan
    Backtrace:
    [<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
     r6:bfad0900 r5:00000000 r4:8088ecc8 r3:bfad0900
    [<80012420>] (show_stack+0x0/0x1c) from [<806169ec>] (dump_stack+0x84/0x9c)
    [<80616968>] (dump_stack+0x0/0x9c) from [<806147b4>] (print_usage_bug+0x260/0x2d0)
     r5:8076ba88 r4:80977410
    [<80614554>] (print_usage_bug+0x0/0x2d0) from [<8005f0d0>] (mark_lock+0x1e0/0x6ac)
     r9:8005e678 r8:00000000 r7:bfad0900 r6:00001015 r5:bfad0cd0
    r4:00000002
    [<8005eef0>] (mark_lock+0x0/0x6ac) from [<80060234>] (__lock_acquire+0x604/0x1cbc)
    [<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] (lock_acquire+0x70/0x84)
    [<80062060>] (lock_acquire+0x0/0x84) from [<8061d1c8>] (_raw_spin_lock+0x30/0x40)
     r7:00000000 r6:bfb63000 r5:00000000 r4:bfb60568
    [<8061d198>] (_raw_spin_lock+0x0/0x40) from [<8045f7f4>] (sdhci_execute_tuning+0x4c/0x710)
     r4:bfb60000
    [<8045f7a8>] (sdhci_execute_tuning+0x0/0x710) from [<80453454>] (mmc_sd_init_card+0x5f8/0x660)
    [<80452e5c>] (mmc_sd_init_card+0x0/0x660) from [<80453748>] (mmc_attach_sd+0xb4/0x180)
     r9:bf92d400 r8:8065f364 r7:00061a80 r6:bfb60000 r5:8065f358
    r4:bfb60000
    [<80453694>] (mmc_attach_sd+0x0/0x180) from [<8044d9f8>] (mmc_rescan+0x284/0x2f0)
     r5:8065f358 r4:bfb602f8
    [<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] (process_one_work+0x1a4/0x468)
     r8:00000000 r7:bfb55eb0 r6:bf80dc00 r5:bfb602f8 r4:bfb35980
    r3:8044d774
    [<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] (worker_thread+0x118/0x3e0)
    [<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0)
    [<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
     r7:00000000 r6:00000000 r5:80044d0c r4:bfb37b40
    
    Signed-off-by: Dong Aisheng <b29396@freescale.com>
    Signed-off-by: Chris Ball <chris@printf.net>
    [bwh: Backported to 3.2:
     - Adjust context
     - There's no platform_execute_tuning hook]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d6d0a918541faf96007b9965ec4a0ff44c9faee8
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 16 09:47:17 2014 -0500

    libata: disable LPM for some WD SATA-I devices
    
    commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.
    
    For some reason, some early WD drives spin up and down drives
    erratically when the link is put into slumber mode which can reduce
    the life expectancy of the device significantly.  Unfortunately, we
    don't have full list of devices and given the nature of the issue it'd
    be better to err on the side of false positives than the other way
    around.  Let's disable LPM on all WD devices which match one of the
    known problematic model prefixes and are SATA-I.
    
    As horkage list doesn't support matching SATA capabilities, this is
    implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
    set for the known prefixes and sets the latter if the matched device
    is SATA-I.
    
    Note that this isn't optimal as this disables all LPM operations and
    partial link power state reportedly works fine on these; however, the
    way LPM is implemented in libata makes it difficult to precisely map
    libata LPM setting to specific link power state.  Well, these devices
    are already fairly outdated.  Let's just disable whole LPM for now.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com>
    Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
    [bwh: Backported to 3.2:
     - Adjust context
     - Use literal 76 instead of ATA_ID_SATA_CAPABILITY]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a7c1da5bf2f334a742de21376f2c37ade925b4a5
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Jan 13 06:51:01 2014 -0500

    x86: Add check for number of available vectors before CPU down
    
    commit da6139e49c7cb0f4251265cb5243b8d220adb48d upstream.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
    
    When a cpu is downed on a system, the irqs on the cpu are assigned to
    other cpus.  It is possible, however, that when a cpu is downed there
    aren't enough free vectors on the remaining cpus to account for the
    vectors from the cpu that is being downed.
    
    This results in an interesting "overflow" condition where irqs are
    "assigned" to a CPU but are not handled.
    
    For example, when downing cpus on a 1-64 logical processor system:
    
    <snip>
    [  232.021745] smpboot: CPU 61 is now offline
    [  238.480275] smpboot: CPU 62 is now offline
    [  245.991080] ------------[ cut here ]------------
    [  245.996270] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x246/0x250()
    [  246.005688] NETDEV WATCHDOG: p786p1 (ixgbe): transmit queue 0 timed out
    [  246.013070] Modules linked in: lockd sunrpc iTCO_wdt iTCO_vendor_support sb_edac ixgbe microcode e1000e pcspkr joydev edac_core lpc_ich ioatdma ptp mdio mfd_core i2c_i801 dca pps_core i2c_core wmi acpi_cpufreq isci libsas scsi_transport_sas
    [  246.037633] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0+ #14
    [  246.044451] Hardware name: Intel Corporation S4600LH ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
    [  246.057371]  0000000000000009 ffff88081fa03d40 ffffffff8164fbf6 ffff88081fa0ee48
    [  246.065728]  ffff88081fa03d90 ffff88081fa03d80 ffffffff81054ecc ffff88081fa13040
    [  246.074073]  0000000000000000 ffff88200cce0000 0000000000000040 0000000000000000
    [  246.082430] Call Trace:
    [  246.085174]  <IRQ>  [<ffffffff8164fbf6>] dump_stack+0x46/0x58
    [  246.091633]  [<ffffffff81054ecc>] warn_slowpath_common+0x8c/0xc0
    [  246.098352]  [<ffffffff81054fb6>] warn_slowpath_fmt+0x46/0x50
    [  246.104786]  [<ffffffff815710d6>] dev_watchdog+0x246/0x250
    [  246.110923]  [<ffffffff81570e90>] ? dev_deactivate_queue.constprop.31+0x80/0x80
    [  246.119097]  [<ffffffff8106092a>] call_timer_fn+0x3a/0x110
    [  246.125224]  [<ffffffff8106280f>] ? update_process_times+0x6f/0x80
    [  246.132137]  [<ffffffff81570e90>] ? dev_deactivate_queue.constprop.31+0x80/0x80
    [  246.140308]  [<ffffffff81061db0>] run_timer_softirq+0x1f0/0x2a0
    [  246.146933]  [<ffffffff81059a80>] __do_softirq+0xe0/0x220
    [  246.152976]  [<ffffffff8165fedc>] call_softirq+0x1c/0x30
    [  246.158920]  [<ffffffff810045f5>] do_softirq+0x55/0x90
    [  246.164670]  [<ffffffff81059d35>] irq_exit+0xa5/0xb0
    [  246.170227]  [<ffffffff8166062a>] smp_apic_timer_interrupt+0x4a/0x60
    [  246.177324]  [<ffffffff8165f40a>] apic_timer_interrupt+0x6a/0x70
    [  246.184041]  <EOI>  [<ffffffff81505a1b>] ? cpuidle_enter_state+0x5b/0xe0
    [  246.191559]  [<ffffffff81505a17>] ? cpuidle_enter_state+0x57/0xe0
    [  246.198374]  [<ffffffff81505b5d>] cpuidle_idle_call+0xbd/0x200
    [  246.204900]  [<ffffffff8100b7ae>] arch_cpu_idle+0xe/0x30
    [  246.210846]  [<ffffffff810a47b0>] cpu_startup_entry+0xd0/0x250
    [  246.217371]  [<ffffffff81646b47>] rest_init+0x77/0x80
    [  246.223028]  [<ffffffff81d09e8e>] start_kernel+0x3ee/0x3fb
    [  246.229165]  [<ffffffff81d0989f>] ? repair_env_string+0x5e/0x5e
    [  246.235787]  [<ffffffff81d095a5>] x86_64_start_reservations+0x2a/0x2c
    [  246.242990]  [<ffffffff81d0969f>] x86_64_start_kernel+0xf8/0xfc
    [  246.249610] ---[ end trace fb74fdef54d79039 ]---
    [  246.254807] ixgbe 0000:c2:00.0 p786p1: initiating reset due to tx timeout
    [  246.262489] ixgbe 0000:c2:00.0 p786p1: Reset adapter
    Last login: Mon Nov 11 08:35:14 from 10.18.17.119
    [root@(none) ~]# [  246.792676] ixgbe 0000:c2:00.0 p786p1: detected SFP+: 5
    [  249.231598] ixgbe 0000:c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
    [  246.792676] ixgbe 0000:c2:00.0 p786p1: detected SFP+: 5
    [  249.231598] ixgbe 0000:c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
    
    (last lines keep repeating.  ixgbe driver is dead until module reload.)
    
    If the downed cpu has more vectors than are free on the remaining cpus on the
    system, it is possible that some vectors are "orphaned" even though they are
    assigned to a cpu.  In this case, since the ixgbe driver had a watchdog, the
    watchdog fired and notified that something was wrong.
    
    This patch adds a function, check_vectors(), to compare the number of vectors
    on the CPU going down and compares it to the number of vectors available on
    the system.  If there aren't enough vectors for the CPU to go down, an
    error is returned and propogated back to userspace.
    
    v2: Do not need to look at percpu irqs
    v3: Need to check affinity to prevent counting of MSIs in IOAPIC Lowest
        Priority Mode
    v4: Additional changes suggested by Gong Chen.
    v5/v6/v7/v8: Updated comment text
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Link: http://lkml.kernel.org/r/1389613861-3853-1-git-send-email-prarit@redhat.com
    Reviewed-by: Gong Chen <gong.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Cc: Yang Zhang <yang.z.zhang@Intel.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Janet Morgan <janet.morgan@intel.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Ruiv Wang <ruiv.wang@gmail.com>
    Cc: Gong Chen <gong.chen@linux.intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit adce73dfdacf706d8e3c389518ff24464965e4f1
Author: NeilBrown <neilb@suse.de>
Date:   Thu Jan 16 09:35:38 2014 +1100

    md/raid5: fix long-standing problem with bitmap handling on write failure.
    
    commit 9f97e4b128d2ea90a5f5063ea0ee3b0911f4c669 upstream.
    
    Before a write starts we set a bit in the write-intent bitmap.
    When the write completes we clear that bit if the write was successful
    to all devices.  However if the write wasn't fully successful we
    should not clear the bit.  If the faulty drive is subsequently
    re-added, the fact that the bit is still set ensure that we will
    re-write the data that is missing.
    
    This logic is mediated by the STRIPE_DEGRADED flag - we only clear the
    bitmap bit when this flag is not set.
    Currently we correctly set the flag if a write starts when some
    devices are failed or missing.  But we do *not* set the flag if some
    device failed during the write attempt.
    This is wrong and can result in clearing the bit inappropriately.
    
    So: set the flag when a write fails.
    
    This bug has been present since bitmaps were introduces, so the fix is
    suitable for any -stable kernel.
    
    Reported-by: Ethan Wilson <ethan.wilson@shiftmail.org>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7a9175abf3816d07fc8b87d74f3b4e4f19728f69
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Mon Jan 6 12:00:02 2014 -0200

    KVM: x86: limit PIT timer frequency
    
    commit 9ed96e87c5748de4c2807ef17e81287c7304186c upstream.
    
    Limit PIT timer frequency similarly to the limit applied by
    LAPIC timer.
    
    Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/ps->period/pt->period/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43057146932997ca54a2326cfd6abe9fe1ec5a9f
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jan 13 19:37:54 2014 -0500

    dm sysfs: fix a module unload race
    
    commit 2995fa78e423d7193f3b57835f6c1c75006a0315 upstream.
    
    This reverts commit be35f48610 ("dm: wait until embedded kobject is
    released before destroying a device") and provides an improved fix.
    
    The kobject release code that calls the completion must be placed in a
    non-module file, otherwise there is a module unload race (if the process
    calling dm_kobject_release is preempted and the DM module unloaded after
    the completion is triggered, but before dm_kobject_release returns).
    
    To fix this race, this patch moves the completion code to dm-builtin.c
    which is always compiled directly into the kernel if BLK_DEV_DM is
    selected.
    
    The patch introduces a new dm_kobject_holder structure, its purpose is
    to keep the completion and kobject in one place, so that it can be
    accessed from non-module code without the need to export the layout of
    struct mapped_device to that code.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Remove paranoid check of container_of() result in dm_get_from_kobject(),
       which would now be incorrect
     - Include <linux/export.h> in dm-builtin.c, included indirectly upstream]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7785833fe6d2c3027d3e385d72bd31775031d2b
Author: Peter Chen <peter.chen@freescale.com>
Date:   Fri Jan 10 13:51:26 2014 +0800

    usb: ehci: add freescale imx28 special write register method
    
    commit feffe09f510c475df082546815f9e4a573f6a233 upstream.
    
    According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
    register error issue", All USB register write operations must
    use the ARM SWP instruction. So, we implement a special ehci_write
    for imx28.
    
    Discussion for it at below:
    http://marc.info/?l=linux-usb&m=137996395529294&w=2
    
    Without this patcheset, imx28 works unstable at high AHB bus loading.
    If the bus loading is not high, the imx28 usb can work well at the most
    of time. There is a IC errata for this problem, usually, we consider
    IC errata is a problem not a new feature, and this workaround is needed
    for that, so we need to add them to stable tree 3.11+.
    
    Cc: robert.hodaszi@digi.com
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2cf3f5e629ff7424e683197e849f598be53a11c
Author: Weston Andros Adamson <dros@primarydata.com>
Date:   Mon Jan 13 16:54:45 2014 -0500

    nfs4.1: properly handle ENOTSUP in SECINFO_NO_NAME
    
    commit 78b19bae0813bd6f921ca58490196abd101297bd upstream.
    
    Don't check for -NFS4ERR_NOTSUPP, it's already been mapped to -ENOTSUPP
    by nfs4_stat_to_errno.
    
    This allows the client to mount v4.1 servers that don't support
    SECINFO_NO_NAME by falling back to the "guess and check" method of
    nfs4_find_root_sec.
    
    Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9d051d0b5bc88d36a53ac5724301b26a7c1bf1c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Jan 9 10:27:27 2014 -0600

    rtlwifi: rtl8192cu: Add new device ID
    
    commit f87f960b2fb802f26ee3b00c19320e57a9c583ff upstream.
    
    Reported-by: Jan Prinsloo <janroot@gmail.com>
    Tested-by: Jan Prinsloo <janroot@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 82d12fc84435b9c815357e306dfd844f54a62714
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Mon Jan 13 12:56:21 2014 -0500

    ftrace: Fix synchronization location disabling and freeing ftrace_ops
    
    commit a4c35ed241129dd142be4cadb1e5a474a56d5464 upstream.
    
    The synchronization needed after ftrace_ops are unregistered must happen
    after the callback is disabled from becing called by functions.
    
    The current location happens after the function is being removed from the
    internal lists, but not after the function callbacks were disabled, leaving
    the functions susceptible of being called after their callbacks are freed.
    
    This affects perf and any externel users of function tracing (LTTng and
    SystemTap).
    
    Fixes: cdbe61bfe704 "ftrace: Allow dynamically allocated function tracers"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    [bwh: Backported to 3.2: drop change for control ops]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>

commit 9f9b9ac2ccbd28e2a07a40abdfc3b598f107933a
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue May 28 20:01:16 2013 -0400

    ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()
    
    commit 7614c3dc74733dff4b0e774f7a894b9ea6ec508c upstream.
    
    The function tracer uses preempt_disable/enable_notrace() for
    synchronization between reading registered ftrace_ops and unregistering
    them.
    
    Most of the ftrace_ops are global permanent structures that do not
    require this synchronization. That is, ops may be added and removed from
    the hlist but are never freed, and wont hurt if a synchronization is
    missed.
    
    But this is not true for dynamically created ftrace_ops or control_ops,
    which are used by the perf function tracing.
    
    The problem here is that the function tracer can be used to trace
    kernel/user context switches as well as going to and from idle.
    Basically, it can be used to trace blind spots of the RCU subsystem.
    This means that even though preempt_disable() is done, a
    synchronize_sched() will ignore CPUs that haven't made it out of user
    space or idle. These can include functions that are being traced just
    before entering or exiting the kernel sections.
    
    To implement the RCU synchronization, instead of using
    synchronize_sched() the use of schedule_on_each_cpu() is performed. This
    means that when a dynamically allocated ftrace_ops, or a control ops is
    being unregistered, all CPUs must be touched and execute a ftrace_sync()
    stub function via the work queues. This will rip CPUs out from idle or
    in dynamic tick mode. This only happens when a user disables perf
    function tracing or other dynamically allocated function tracers, but it
    allows us to continue to debug RCU and context tracking with function
    tracing.
    
    Link: http://lkml.kernel.org/r/1369785676.15552.55.camel@gandalf.local.home
    
    Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    [bwh: Backported to 3.2: drop change for control ops]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c98df443b8a9bd7573cf7c556bdf4aa7a192188b
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Wed Nov 20 16:01:11 2013 +0100

    mmc: atmel-mci: fix timeout errors in SDIO mode when using DMA
    
    commit 66b512eda74d59b17eac04c4da1b38d82059e6c9 upstream.
    
    With some SDIO devices, timeout errors can happen when reading data.
    To solve this issue, the DMA transfer has to be activated before sending
    the command to the device. This order is incorrect in PDC mode. So we
    have to take care if we are using DMA or PDC to know when to send the
    MMC command.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96540b62efda4daf7654678e00361fc8ed3a4473
Author: Hartmut Knaack <knaack.h@gmx.de>
Date:   Wed Jan 1 23:04:00 2014 +0000

    staging:iio:ad799x fix error_free_irq which was freeing an irq that may not have been requested
    
    commit 38408d056188be29a6c4e17f3703c796551bb330 upstream.
    
    Only free an IRQ in error_free_irq, if it has been requested previously.
    
    Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7e031b8d7fdec31c0c50b7f972524d11d5905d4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jan 10 14:20:42 2014 +0100

    ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks
    
    commit 80ab8eae70e51d578ebbeb228e0f7a562471b8b7 upstream.
    
    The PCI devices with DMA masks smaller than 32bit should enable
    CONFIG_ZONE_DMA.  Since the recent change of page allocator, page
    allocations via dma_alloc_coherent() with the limited DMA mask bits
    may fail more frequently, ended up with no available buffers, when
    CONFIG_ZONE_DMA isn't enabled.  With CONFIG_ZONE_DMA, the system has
    much more chance to obtain such pages.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 900a2253be2a79bec23e572fa84b1a8844e497c4
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Dec 24 11:22:54 2013 -0600

    staging: r8712u: Set device type to wlan
    
    commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream.
    
    The latest version of NetworkManager does not recognize the device as wireless
    without this change.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3d42de37001784d4e00c2e2cd6e4fdb983a76e21
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 8 11:40:20 2014 +0900

    radeon/pm: Guard access to rdev->pm.power_state array
    
    commit 370169516e736edad3b3c5aa49858058f8b55195 upstream.
    
    It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.
    
    Should fix an oops I encountered while resetting the GPU after a lockup
    on my PowerBook with an RV350.
    
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 09c18c601e918a88c431cf4e540eafa5bc25fcc1
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Wed Jan 8 11:22:25 2014 +0100

    ASoC: adau1701: Fix ADAU1701_SEROCTL_WORD_LEN_16 constant
    
    commit e20970ada3f699c113fe64b04492af083d11a7d8 upstream.
    
    The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10,
    so 0x2. This patch fixes it.
    
    Reported-by: Magnus Reftel <magnus.reftel@lockless.no>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da159c8e81382a7fd65d0d6a612999aecfaf4ca5
Author: Joe Thornber <ejt@redhat.com>
Date:   Tue Jan 7 15:47:59 2014 +0000

    dm space map common: make sure new space is used during extend
    
    commit 12c91a5c2d2a8e8cc40a9552313e1e7b0a2d9ee3 upstream.
    
    When extending a low level space map we should update nr_blocks at
    the start so the new space is used for the index entries.
    
    Otherwise extend can fail, e.g.: sm_metadata_extend call sequence
    that fails:
     -> sm_ll_extend
        -> dm_tm_new_block -> dm_sm_new_block -> sm_bootstrap_new_block
        => returns -ENOSPC because smm->begin == smm->ll.nr_blocks
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1765b496a0a8b2d8d9c840fa748986f0ca93198f
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jan 6 23:01:22 2014 -0500

    dm: wait until embedded kobject is released before destroying a device
    
    commit be35f486108227e10fe5d96fd42fb2b344c59983 upstream.
    
    There may be other parts of the kernel holding a reference on the dm
    kobject.  We must wait until all references are dropped before
    deallocating the mapped_device structure.
    
    The dm_kobject_release method signals that all references are dropped
    via completion.  But dm_kobject_release doesn't free the kobject (which
    is embedded in the mapped_device structure).
    
    This is the sequence of operations:
    * when destroying a DM device, call kobject_put from dm_sysfs_exit
    * wait until all users stop using the kobject, when it happens the
      release method is called
    * the release method signals the completion and should return without
      delay
    * the dm device removal code that waits on the completion continues
    * the dm device removal code drops the dm_mod reference the device had
    * the dm device removal code frees the mapped_device structure that
      contains the kobject
    
    Using kobject this way should avoid the module unload race that was
    mentioned at the beginning of this thread:
    https://lkml.org/lkml/2014/1/4/83
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 220ff586da578215e1cef7f2d89ef35b65965ce5
Author: Stephen Warren <swarren@nvidia.com>
Date:   Tue Jan 7 15:00:12 2014 -0700

    serial: 8250: enable UART_BUG_NOMSR for Tegra
    
    commit 3685f19e07802ec4207b52465c408f185b66490e upstream.
    
    Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
    their MODEM-control signals tied off to a static state. However UARTs A
    and B can optionally route those signals to/from package pins, depending
    on the exact pinmux configuration.
    
    When these signals are not routed to package pins, false interrupts may
    trigger either temporarily, or permanently, all while not showing up in
    the IIR; it will read as NO_INT. This will eventually lead to the UART
    IRQ being disabled due to unhandled interrupts. When this happens, the
    kernel may print e.g.:
    
        irq 68: nobody cared (try booting with the "irqpoll" option)
    
    In order to prevent this, enable UART_BUG_NOMSR. This prevents
    UART_IER_MSI from being enabled, which prevents the false interrupts
    from triggering.
    
    In practice, this is not needed under any of the following conditions:
    
    * On Tegra chips after Tegra30, since the HW bug has apparently been
      fixed.
    
    * On UARTs C..E since their MODEM control signals are tied to the correct
      static state which doesn't trigger the issue.
    
    * On UARTs A..B if the MODEM control signals are routed out to package
      pins, since they will then carry valid signals.
    
    However, we ignore these exceptions for now, since they are only relevant
    if a board actually hooks up more than a 4-wire UART, and no currently
    supported board does this. If we ever support a board that does, we can
    refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
    into account, and/or read a flag from DT/... that indicates that the
    board has hooked up and pinmux'd more than a 4-wire UART.
    
    Reported-by: Olof Johansson <olof@lixom.net> # autotester
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:
     - Adjust filename
     - s/port->/up->port./]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9e397d2a211c54ef195f39786ea5986db4ef20dd
Author: Colin Leitner <colin.leitner@googlemail.com>
Date:   Mon Jan 6 21:33:54 2014 +0100

    USB: ftdi_sio: added CS5 quirk for broken smartcard readers
    
    commit c1f15196ac3b541d084dc80a8fbd8a74c6a0bd44 upstream.
    
    Genuine FTDI chips support only CS7/8. A previous fix in commit
    8704211f65a2 ("USB: ftdi_sio: fixed handling of unsupported CSIZE
    setting") enforced this limitation and reported it back to userspace.
    
    However, certain types of smartcard readers depend on specific
    driver behaviour that requests 0 data bits (not 5) to change into a
    different operating mode if CS5 has been set.
    
    This patch reenables this behaviour for all FTDI devices.
    
    Tagged to be added to stable, because it affects a lot of users of
    embedded systems which rely on these readers to work properly.
    
    Reported-by: Heinrich Siebmanns <H.Siebmanns@t-online.de>
    Tested-by: Heinrich Siebmanns <H.Siebmanns@t-online.de>
    Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: s/ddev/\&port->dev/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2b5e579e01252cd65b073360eec69042ea77affc
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 7 10:05:02 2014 -0500

    drm/radeon: warn users when hw_i2c is enabled (v2)
    
    commit d195178297de9a91246519dbfa98952b70f9a9b6 upstream.
    
    The hw i2c engines are disabled by default as the
    current implementation is still experimental.  Print
    a warning when users enable it so that it's obvious
    when the option is enabled.
    
    v2: check for non-0 rather than 1
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 04f8113c2da4027d04a9f7aaa24813fca669a439
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Jan 6 21:28:15 2014 +0900

    SELinux: Fix memory leak upon loading policy
    
    commit 8ed814602876bec9bad2649ca17f34b499357a1c upstream.
    
    Hello.
    
    I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .
    
    [  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    
    Below is a patch, but I don't know whether we need special handing for undoing
    ebitmap_set_bit() call.
    ----------
    >>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
    From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Date: Mon, 6 Jan 2014 16:30:21 +0900
    Subject: [PATCH] SELinux: Fix memory leak upon loading policy
    
    Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
    check return value from hashtab_insert() in filename_trans_read(). It leaks
    memory if hashtab_insert() returns error.
    
      unreferenced object 0xffff88005c9160d0 (size 8):
        comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
        hex dump (first 8 bytes):
          57 0b 00 00 6b 6b 6b a5                          W...kkk.
        backtrace:
          [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
          [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
          [<ffffffff812b345c>] security_load_policy+0x6c/0x500
          [<ffffffff812a623c>] sel_write_load+0xac/0x750
          [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
          [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
          [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff
    
    However, we should not return EEXIST error to the caller, or the systemd will
    show below message and the boot sequence freezes.
    
      systemd[1]: Failed to load SELinux policy. Freezing.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a1114e5c73bbcc5acfabc9de4b79635d82071c03
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Tue Dec 17 12:16:11 2013 -0500

    sunrpc: Fix infinite loop in RPC state machine
    
    commit 6ff33b7dd0228b7d7ed44791bbbc98b03fd15d9d upstream.
    
    When a task enters call_refreshresult with status 0 from call_refresh and
    !rpcauth_uptodatecred(task) it enters call_refresh again with no rate-limiting
    or max number of retries.
    
    Instead of trying forever, make use of the retry path that other errors use.
    
    This only seems to be possible when the crrefresh callback is gss_refresh_null,
    which only happens when destroying the context.
    
    To reproduce:
    
    1) mount with sec=krb5 (or sec=sys with krb5 negotiated for non FSID specific
       operations).
    
    2) reboot - the client will be stuck and will need to be hard rebooted
    
    BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:2:46]
    Modules linked in: rpcsec_gss_krb5 nfsv4 nfs fscache ppdev crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd serio_raw i2c_piix4 i2c_core e1000 parport_pc parport shpchp nfsd auth_rpcgss oid_registry exportfs nfs_acl lockd sunrpc autofs4 mptspi scsi_transport_spi mptscsih mptbase ata_generic floppy
    irq event stamp: 195724
    hardirqs last  enabled at (195723): [<ffffffff814a925c>] restore_args+0x0/0x30
    hardirqs last disabled at (195724): [<ffffffff814b0a6a>] apic_timer_interrupt+0x6a/0x80
    softirqs last  enabled at (195722): [<ffffffff8103f583>] __do_softirq+0x1df/0x276
    softirqs last disabled at (195717): [<ffffffff8103f852>] irq_exit+0x53/0x9a
    CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc3-branch-dros_testing+ #4
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
    Workqueue: rpciod rpc_async_schedule [sunrpc]
    task: ffff8800799c4260 ti: ffff880079002000 task.ti: ffff880079002000
    RIP: 0010:[<ffffffffa0064fd4>]  [<ffffffffa0064fd4>] __rpc_execute+0x8a/0x362 [sunrpc]
    RSP: 0018:ffff880079003d18  EFLAGS: 00000246
    RAX: 0000000000000005 RBX: 0000000000000007 RCX: 0000000000000007
    RDX: 0000000000000007 RSI: ffff88007aecbae8 RDI: ffff8800783d8900
    RBP: ffff880079003d78 R08: ffff88006e30e9f8 R09: ffffffffa005a3d7
    R10: ffff88006e30e7b0 R11: ffff8800783d8900 R12: ffffffffa006675e
    R13: ffff880079003ce8 R14: ffff88006e30e7b0 R15: ffff8800783d8900
    FS:  0000000000000000(0000) GS:ffff88007f200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f3072333000 CR3: 0000000001a0b000 CR4: 00000000001407f0
    Stack:
     ffff880079003d98 0000000000000246 0000000000000000 ffff88007a9a4830
     ffff880000000000 ffffffff81073f47 ffff88007f212b00 ffff8800799c4260
     ffff8800783d8988 ffff88007f212b00 ffffe8ffff604800 0000000000000000
    Call Trace:
     [<ffffffff81073f47>] ? trace_hardirqs_on_caller+0x145/0x1a1
     [<ffffffffa00652d3>] rpc_async_schedule+0x27/0x32 [sunrpc]
     [<ffffffff81052974>] process_one_work+0x211/0x3a5
     [<ffffffff810528d5>] ? process_one_work+0x172/0x3a5
     [<ffffffff81052eeb>] worker_thread+0x134/0x202
     [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
     [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
     [<ffffffff810584a0>] kthread+0xc9/0xd1
     [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
     [<ffffffff814afd6c>] ret_from_fork+0x7c/0xb0
     [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
    Code: e8 87 63 fd e0 c6 05 10 dd 01 00 01 48 8b 43 70 4c 8d 6b 70 45 31 e4 a8 02 0f 85 d5 02 00 00 4c 8b 7b 48 48 c7 43 48 00 00 00 00 <4c> 8b 4b 50 4d 85 ff 75 0c 4d 85 c9 4d 89 cf 0f 84 32 01 00 00
    
    And the output of "rpcdebug -m rpc -s all":
    
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    
    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fcff6f399adcb23862b5f2cee1a3bcf8fc1926c7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 27 00:13:08 2013 +0200

    ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]
    
    commit 770bd4bf2e664939a9dacd3d26ec9ff7a3933210 upstream.
    
    The lack of comma leads to the wrong channel for an SPDIF channel.
    Unfortunately this wasn't caught by compiler because it's still a
    valid expression.
    
    Reported-by: Alexander Aristov <aristov.alexander@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9210bf58990e9a323104dc648a8e4c8ef1c4c20b
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Jan 2 22:49:24 2014 +0100

    USB: cypress_m8: fix ring-indicator detection and reporting
    
    commit 440ebadeae9298d7de3d4d105342691841ec88d0 upstream.
    
    Fix ring-indicator (RI) status-bit definition, which was defined as CTS,
    effectively preventing RI-changes from being detected while reporting
    false RI status.
    
    This bug predates git.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0149978efa3d55629acd652ed35d3dd7f52e256c
Author: Mikhail Zolotaryov <lebon@lebon.org.ua>
Date:   Sat Dec 28 01:56:35 2013 +0200

    USB: Nokia 502 is an unusual device
    
    commit 0e16114f2db4838251fb64f3b550996ad3585890 upstream.
    
    The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha
    Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered
    files are corrupted). A similar issue is described here:
    http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170
    
    The workaround is (MAX_SECTORS_64):
       rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m
    
    The patch adds the tested device to the unusual list permanently.
    
    Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ea72634bf522f48d2bf3e14dd998456d54f9371b
Author: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Date:   Thu Jan 2 20:57:56 2014 +0530

    USB: serial: add support for iBall 3.5G connect usb modem
    
    commit 7d5c1b9c7cb5ec8e52b1adc65c484a923a8ea6c3 upstream.
    
    Add support for iBall 3.5G connect usb modem.
    
    $lsusb
    Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY
    
    $usb-devices
    T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1c9e ProdID=9605 Rev=00.00
    S:  Manufacturer=USB Modem
    S:  Product=USB Modem
    S:  SerialNumber=1234567890ABCDEF
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    
    Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
    Suggested-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f0c906da142a5bd2ed8e67230466c8483dd18dab
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Dec 29 19:22:53 2013 +0100

    USB: pl2303: fix data corruption on termios updates
    
    commit 623c8263376c0b8a4b0c220232e7313d762cd0cc upstream.
    
    Some PL2303 devices are known to lose bytes if you change serial
    settings even to the same values as before. Avoid this by comparing the
    encoded settings with the previsouly used ones before configuring the
    device.
    
    The common case was fixed by commit bf5e5834bffc6 ("pl2303: Fix mode
    switching regression"), but this problem was still possible to trigger,
    for instance, by using the TCSETS2-interface to repeatedly request
    115201 baud, which gets mapped to 115200 and thus always triggers a
    settings update.
    
    Cc: Frank Schäfer <fschaefer.oss@googlemail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context; use dbg() instead of dev_dbg()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a0809936e2ad052ef0fbdba0e258bfaf0c0dc9bc
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Fri Nov 29 14:14:29 2013 +0100

    mtd: mxc_nand: remove duplicated ecc_stats counting
    
    commit 0566477762f9e174e97af347ee9c865f908a5647 upstream.
    
    The ecc_stats.corrected count variable will already be incremented in
    the above framework-layer just after this callback.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 78d926c3e43b2332393d3b203d62934f8fc73401
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Sep 10 11:43:37 2013 +0800

    slub: Fix calculation of cpu slabs
    
    commit 8afb1474db4701d1ab80cd8251137a3260e6913e upstream.
    
      /sys/kernel/slab/:t-0000048 # cat cpu_slabs
      231 N0=16 N1=215
      /sys/kernel/slab/:t-0000048 # cat slabs
      145 N0=36 N1=109
    
    See, the number of slabs is smaller than that of cpu slabs.
    
    The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
    ("slub: per cpu cache for partial pages").
    
    We should use page->pages instead of page->pobjects when calculating
    the number of cpu partial slabs. This also fixes the mapping of slabs
    and nodes.
    
    As there's no variable storing the number of total/active objects in
    cpu partial slabs, and we don't have user interfaces requiring those
    statistics, I just add WARN_ON for those cases.
    
    Acked-by: Christoph Lameter <cl@linux.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c1ce34960af581bb75f423b2fae6cb82304743c0
Author: Borislav Petkov <bp@alien8.de>
Date:   Sat Jul 20 19:00:23 2013 +0200

    rtc-cmos: Add an alarm disable quirk
    
    commit d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d upstream.
    
    41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
    functionality to disable the RTC wake alarm when shutting down the box.
    
    However, there are at least two b0rked BIOSes we know about:
    
    https://bugzilla.novell.com/show_bug.cgi?id=812592
    https://bugzilla.novell.com/show_bug.cgi?id=805740
    
    where, when wakeup alarm is enabled in the BIOS, the machine reboots
    automatically right after shutdown, regardless of what wakeup time is
    programmed.
    
    Bisecting the issue lead to this patch so disable its functionality with
    a DMI quirk only for those boxes.
    
    Cc: Brecht Machiels <brecht@mos6581.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Rabin Vincent <rabin.vincent@stericsson.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    [jstultz: Changed variable name for clarity, added extra dmi entry]
    Tested-by: Brecht Machiels <brecht@mos6581.org>
    Tested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4eee0d12bad290f9d0b8a76165b38fc287ce3303
Author: Dave Young <dyoung@redhat.com>
Date:   Fri Dec 20 18:02:15 2013 +0800

    x86/efi: Fix off-by-one bug in EFI Boot Services reservation
    
    commit a7f84f03f660d93574ac88835d056c0d6468aebe upstream.
    
    Current code check boot service region with kernel text region by:
    start+size >= __pa_symbol(_text)
    The end of the above region should be start + size - 1 instead.
    
    I see this problem in ovmf + Fedora 19 grub boot:
    text start: 1000000 md start: 800000 md size: 800000
    
    Signed-off-by: Dave Young <dyoung@redhat.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Acked-by: Toshi Kani <toshi.kani@hp.com>
    Tested-by: Toshi Kani <toshi.kani@hp.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [bwh: Backported to 3.2: s/__pa_symbol/virt_to_phys/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 88939e54e5687e9a4dd5d36126788158b8bee545
Author: Yegor Yefremov <yegorslists@googlemail.com>
Date:   Mon Dec 9 12:11:15 2013 +0100

    serial: add support for 200 v3 series Titan card
    
    commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.
    
    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dac3a5cedc13a8a5433c9ab16f2255400a7bab27
Author: Yegor Yefremov <yegor_sub1@visionsystems.de>
Date:   Tue Dec 27 15:47:37 2011 +0100

    serial: add support for 400 and 800 v3 series Titan cards
    
    commit 1e9deb118ed76b9df89d189f27a06522a03cf743 upstream.
    
    add support for 400Hv3, 410Hv3 and 800Hv3
    
    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c54c36c41b6cd911e5df0e7587451ef1218a2a84
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date:   Fri Dec 13 10:35:03 2013 -0300

    dib8000: make 32 bits read atomic
    
    commit 5ac64ba12aca3bef18e61c866583155a3bbf81c4 upstream.
    
    As the dvb-frontend kthread can be called anytime, it can race
    with some get status ioctl. So, it seems better to avoid one to
    race with the other while reading a 32 bits register.
    I can't see any other reason for having a mutex there at I2C, except
    to provide such kind of protection, as the I2C core already has a
    mutex to protect I2C transfers.
    
    Note: instead of this approach, it could eventually remove the dib8000
    specific mutex for it, and either group the 4 ops into one xfer or
    to manually control the I2C mutex. The main advantage of the current
    approach is that the changes are smaller and more puntual.
    
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Acked-by: Patrick Boettcher <pboettcher@kernellabs.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc12cd1954a93e996efb15b4d333ab05788d58fa
Author: 张君 <zjn77777@163.com>
Date:   Wed Dec 18 15:37:17 2013 +0800

    usb: option: add new zte 3g modem pids to option driver
    
    commit 4d90b819ae4c7ea8fd5e2bb7edc68c0f334be2e4 upstream.
    
    Signed-off-by: Jun zhang <zhang.jun92@zte.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b482f7d9e1d70c0b93d26c994cbee3e7143573ae
Author: Vijaya Mohan Guvva <vmohan@brocade.com>
Date:   Wed Dec 4 05:43:58 2013 -0800

    bfa: Chinook quad port 16G FC HBA claim issue
    
    commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.
    
    Bfa driver crash is observed while pushing the firmware on to chinook
    quad port card due to uninitialized bfi_image_ct2 access which gets
    initialized only for CT2 ASIC based cards after request_firmware().
    For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting
    initialized as there is no check for chinook PCI device ID before
    request_firmware and instead bfi_image_cb is initialized as it is the
    default case for card type check.
    
    This patch includes changes to read the right firmware for quad port chinook.
    
    Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7e53b282681234988e3840519e17142cd89595e5
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Sun Dec 8 09:11:30 2013 +0000

    staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity on bScanning
    
    commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream.
    
    byBBPreEDIndex value is initially 0, this means that from
    cold BBvUpdatePreEDThreshold is never set.
    
    This means that sensitivity may be in an ambiguous state,
    failing to scan any wireless points or at least distant ones.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6bd914084b92f8d5b875f1c0f0178ecb439d075e
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Wed Nov 27 17:43:43 2013 +0100

    parport: parport_pc: remove double PCI ID for NetMos
    
    commit d6a484520c5572a4170fa915109ccfc0c38f5008 upstream.
    
    In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added
    the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which
    was at the v2.4.26 time frame. The patch made into 2.6.14.
    Shortly before that patch akpm merged commit 296d3c783b ("[PATCH] Support
    NetMOS based PCI cards providing serial and parallel ports") which made
    into v2.6.9-rc1.
    Now we have two different entries for the same PCI id.
    I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode.
    This patch takes Max's entry for titan_1284p1 (base != -1 specifies the
    ioport for ECP mode) and replaces akpm's entry for netmos_9805 which
    specified -1 (=none). Both share the same PCI-ID (my card has subsystem
    0x1000 / 0x0020 so it should match PCI_ANY).
    
    While here I also drop the entry for titan_1284p2 which is the same as
    netmos_9815.
    
    Cc: Maximilian Attems <maks@stro.at>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8761c43b8cfdb6aa4d69d3b9a3d5f94a52945cde
Author: Paul Moore <pmoore@redhat.com>
Date:   Mon Dec 9 16:11:53 2013 -0500

    selinux: process labeled IPsec TCP SYN-ACK packets properly in selinux_ip_postroute()
    
    commit 5c6c26813a209e7075baf908e3ad81c1a9d389e8 upstream.
    
    Due to difficulty in arriving at the proper security label for
    TCP SYN-ACK packets in selinux_ip_postroute(), we need to check packets
    while/before they are undergoing XFRM transforms instead of waiting
    until afterwards so that we can determine the correct security label.
    
    Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    [bwh: Backported to 3.2:
     s/selinux_peerlbl_enabled()/netlbl_enabled() || selinux_xfrm_enabled()/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5144a343d0579973a631112decba5d0ced76e5c7
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Dec 4 17:39:23 2013 -0500

    NFSv4: OPEN must handle the NFS4ERR_IO return code correctly
    
    commit c7848f69ec4a8c03732cde5c949bd2aa711a9f4b upstream.
    
    decode_op_hdr() cannot distinguish between an XDR decoding error and
    the perfectly valid errorcode NFS4ERR_IO. This is normally not a
    problem, but for the particular case of OPEN, we need to be able
    to increment the NFSv4 open sequence id when the server returns
    a valid response.
    
    Reported-by: J Bruce Fields <bfields@fieldses.org>
    Link: http://lkml.kernel.org/r/20131204210356.GA19452@fieldses.org
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2d6daf8d9db516be660c2e1646925c42eff942e0
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Nov 18 11:11:34 2013 -0600

    rtlwifi: rtl8192cu: Fix some code in RF handling
    
    commit e9b0784bb9de3152e787ee779868c626b137fb3b upstream.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96e6804299cbaef16b4feeccc432c864f161f288
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Nov 18 11:11:28 2013 -0600

    rtlwifi: Set the link state
    
    commit 619ce76f8bb850b57032501a39f26aa6c6731c70 upstream.
    
    The present code fails to set the linked state when an interface is
    added.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>