Squashed update 3.4.82 to 3.4.93

commit 8f81f41f41b335ba433c5d1e6b874dd697c6543e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 11 12:25:24 2014 -0700

    Linux 3.4.93

commit 3e9b2d8cda1178a6ad8fccab6c2f6b4fd4803c96
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Nov 16 14:15:00 2012 -0800

    mm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address

    commit 498c2280212327858e521e9d21345d4cc2637f54 upstream.

    kmap_to_page returns the corresponding struct page for a virtual address
    of an arbitrary mapping.  This works by checking whether the address
    falls in the pkmap region and using the pkmap page tables instead of the
    linear mapping if appropriate.

    Unfortunately, the bounds checking means that PKMAP_ADDR(LAST_PKMAP) is
    incorrectly treated as a highmem address and we can end up walking off
    the end of pkmap_page_table and subsequently passing junk to pte_page.

    This patch fixes the bound check to stay within the pkmap tables.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30560f917273741e3fd121365cf58b6667496040
Author: Scott Ashcroft <scott.ashcroft@talk21.com>
Date:   Sun Mar 3 21:35:06 2013 +0000

    Fix 4 port and add support for 8 port 'Unknown' PCI serial port cards

    commit d13402a4a944e72612a9ec5c9190e35717c02a9d upstream.

    I've managed to find an 8 port version of the card 4 port card which was discussed here:

    http://marc.info/?l=linux-serial&m=120760744205314&w=2

    Looking back at that thread there were two issues in the original patch.

    1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post.
    2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return.

    This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card.

    $ lspci -vvv -n -s 00:08.0
    00:08.0 0780: 10b5:9050 (rev 01)
    	Subsystem: 10b5:1588
    	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    	Interrupt: pin A routed to IRQ 17
    	Region 1: I/O ports at ff00 [size=128]
    	Region 2: I/O ports at fe00 [size=64]
    	Region 3: I/O ports at fd00 [size=8]
    	Capabilities: <access denied>
    	Kernel driver in use: serial

    $ dmesg | grep 0000:00:08.0:
    [    0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780
    [    0.083355] pci 0000:00:08.0: reg 14: [io  0xff00-0xff7f]
    [    0.083369] pci 0000:00:08.0: reg 18: [io  0xfe00-0xfe3f]
    [    0.083382] pci 0000:00:08.0: reg 1c: [io  0xfd00-0xfd07]
    [    0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot
    [    1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A
    [    1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A
    [    1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A
    [    1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A
    [    1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A
    [    1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A
    [    1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A
    [    1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A

    Signed-off-by: Scott Ashcroft <scott.ashcroft@talk21.com>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3701cb0653a6d976060a4144891037f2a26f9e81
Author: Ilya Zykov <ilya@ilyx.ru>
Date:   Mon Mar 4 23:19:41 2013 +0400

    tty: Correct tty buffer flush.

    commit 64325a3be08d364a62ee8f84b2cf86934bc2544a upstream.

      The root of problem is carelessly zeroing pointer(in function __tty_buffer_flush()),
    when another thread can use it. It can be cause of "NULL pointer dereference".
      Main idea of the patch, this is never free last (struct tty_buffer) in the active buffer.
    Only flush the data for ldisc(buf->head->read = buf->head->commit).
    At that moment driver can collect(write) data in buffer without conflict.
    It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.

    Signed-off-by: Ilya Zykov <ilya@ilyx.ru>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a43cd30a1683e09f143191792978292c34a6b650
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:49 2013 +0200

    serial: pch_uart: fix tty-kref leak in rx-error path

    commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

    Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
    deadlock when pch_uart as console") which never put its tty reference.

    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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dd497076f5e2798715c91f1114278d64863062d
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:50 2013 +0200

    serial: pch_uart: fix tty-kref leak in dma-rx path

    commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

    Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

    Note that the tty ref isn't really needed anymore, but as the leak has
    always been there, fixing it before removing should makes it easier to
    backport the fix.

    Signed-off-by: Johan Hovold <jhovold@gmail.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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac0f63901a375183abadfdaef0659cae5ed7a43a
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Wed Dec 5 12:08:29 2012 +0100

    target/file: Fix 32-bit highmem breakage for SGL -> iovec mapping

    commit 40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf upstream.

    This patch changes vectored file I/O to use kmap + kunmap when mapping
    incoming SGL memory -> struct iovec in order to properly support 32-bit
    highmem configurations.  This is because an extra bounce buffer may be
    required when processing scatterlist pages allocated with GFP_KERNEL.

    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: use task->task_sg{,_nents} for iteration]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41440749dfa9375ee3fa3e2be4fd126fe90e63b8
Author: Hannes Reinecke <hare@suse.de>
Date:   Mon Dec 17 09:53:32 2012 +0100

    target: use correct sense code for LUN communication failure

    commit 18a9df42d53fabfa43b78be1104838cc8b9762e1 upstream.

    The ASC/ASCQ code for 'Logical Unit Communication failure' is
    0x08/0x00; 0x80/0x00 is vendor specific.

    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Cc: Nicholas Bellinger <nab@risingtidesystems.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: add offset to buffer index]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9c221716c9c5c3b1b7097ca9e1ab1a19d1e727c
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed May 16 21:52:10 2012 -0700

    target: Fix MAINTENANCE_IN service action CDB checks to use lower 5 bits

    commit ba539743b70cd160c84bab1c82910d0789b820f8 upstream.

    This patch fixes the MAINTENANCE_IN service action type checks to only
    look at the proper lower 5 bits of cdb byte 1.  This addresses the case
    where MI_REPORT_TARGET_PGS w/ extended header using the upper three bits of
    cdb byte 1 was not processed correctly in transport_generic_cmd_sequencer,
    as well as the three cases for standby, unavailable, and transition ALUA
    primary access state checks.

    Also add MAINTENANCE_IN to the excluded list in transport_generic_prepare_cdb()
    to prevent the PARAMETER DATA FORMAT bits from being cleared.

    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Rob Evers <revers@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b848abd5598575f6a8d5c7119a186552c7dc4faa
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Oct 25 21:53:33 2013 +0800

    target/pscsi: fix return value check

    commit 58932e96e438cd78f75e765d7b87ef39d3533d15 upstream.

    In case of error, the function scsi_host_lookup() returns NULL
    pointer not ERR_PTR(). The IS_ERR() test in the return value check
    should be replaced with NULL test.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: pscsi_configure_device() returns a pointer]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a80eb9e57a292683346a4eb16f82fdb2d038abae
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Nov 5 18:02:42 2012 -0800

    iscsi-target: Always send a response before terminating iSCSI connection

    commit 1c5c12c666fda27c7c494b34934a0a0631a48130 upstream.

    There are some cases, for example when the initiator sends an
    out-of-bounds ErrorRecoveryLevel value, where the iSCSI target
    terminates the connection without sending back any error.  Audit the
    login path and add appropriate iscsit_tx_login_rsp() calls to make
    sure this doesn't happen.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0e70135a5f02394b7b86b35de5a96f87d50f071
Author: Mike Miller <mike.miller@hp.com>
Date:   Thu Sep 20 16:05:18 2012 -0500

    hpsa: gen8plus Smart Array IDs

    commit fe0c9610bb68dd0aad1017456f5e3c31264d70c2 upstream.

    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45ef42f91909747f70808add5ae673032b2e6f42
Author: Reddy, Sreekanth <Sreekanth.Reddy@lsi.com>
Date:   Tue Feb 26 16:59:59 2013 +0530

    mpt2sas: Fix for issue Missing delay not getting set during system bootup

    commit 93cfcb8c998e3fe2c075fa61ab28f7b018e5049a upstream.

    commit b0df96a0068daee4f9c2189c29b9053eb6e46b17 upstream.

    Missing delay is not getting set properly. The reason is that it is not
    defined in the same file from where it is being invoked.  The fix is to move
    the missing delay module parameter from mpt2sas_base.c to mpt2sas_scsh.c.

    Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9048664ce1f060e88b00898f8976e1af854e696b
Author: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Date:   Sat Feb 2 00:56:18 2013 +0530

    mpt2sas: Fix for device scan following host reset could get stuck in a infinite loop

    commit 6241f22ca12a26ee149cbe31b27bac97dbdc8bc4 upstream.

    Modified device scan routine so each configuration page read breaks from the
    while loop when the ioc_status is not equal to MPI2_IOCSTATUS_SUCCESS.

    [jejb: checkpatch fixes]
    Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62ddd54e2366b02b985e60684b87ee8cb5cd7201
Author: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Date:   Thu Jul 11 17:18:58 2013 -0700

    isci: Fix a race condition in the SSP task management path

    commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream.

    This commit fixes a race condition in the isci driver abort task and SSP
    device task management path.  The race is caused when an I/O termination
    in the SCU hardware is necessary because of an SSP target timeout condition,
    and the check of the I/O end state races against the HW-termination-driven
    end state.  The failure of the race meant that no TMF was sent to the device
    to clean-up the pending I/O.

    Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
    Reviewed-by: Lukasz Dorau <lukasz.dorau@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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18db4dc78c8c64c7b86638a7a46e3f34cf5f9af3
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Wed Feb 26 16:50:01 2014 +0300

    nfsd: check passed socket's net matches NFSd superblock's one

    commit 3064639423c48d6e0eb9ecc27c512a58e38c6c57 upstream.

    There could be a case, when NFSd file system is mounted in network, different
    to socket's one, like below:

    "ip netns exec" creates new network and mount namespace, which duplicates NFSd
    mount point, created in init_net context. And thus NFS server stop in nested
    network context leads to RPCBIND client destruction in init_net.
    Then, on NFSd start in nested network context, rpc.nfsd process creates socket
    in nested net and passes it into "write_ports", which leads to RPCBIND sockets
    creation in init_net context because of the same reason (NFSd monut point was
    created in init_net context). An attempt to register passed socket in nested
    net leads to panic, because no RPCBIND client present in nexted network
    namespace.

    This patch add check that passed socket's net matches NFSd superblock's one.
    And returns -EINVAL error to user psace otherwise.

    v2: Put socket on exit.

    Reported-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4: adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee30258737871ee43510111f2f0a37793bea08bb
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Fri Feb 1 15:56:12 2013 +0300

    nfsd: containerize NFSd filesystem

    note: this backport is just for the null pointer problem when
    start nfsd in none init netns. The nfsd is still not containerized.

    commit 11f779421a39b86da8a523d97e5fd3477878d44f upstream.

    This patch makes NFSD file system superblock to be created per net.
    This makes possible to get proper network namespace from superblock instead of
    using hard-coded "init_net".

    Note: NFSd fs super-block holds network namespace. This garantees, that
    network namespace won't disappear from underneath of it.
    This, obviously, means, that in case of kill of a container's "init" (which is not a mount
    namespace, but network namespace creator) netowrk namespace won't be
    destroyed.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4:
     - export cache not per netns
     - NFSD service structure not per netns]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b756a48953050d24987e7f4b391119017e0f1a7
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Thu Dec 6 18:34:42 2012 +0300

    nfsd: pass proper net to nfsd_destroy() from NFSd kthreads

    commit 88c47666171989ed4c5b1a5687df09511e8c5e35 upstream.

    Since NFSd service is per-net now, we have to pass proper network
    context in nfsd_shutdown() from NFSd kthreads.

    The simplest way I found is to get proper net from one of transports
    with permanent sockets.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4: adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a79a06e79b446d7d0b7403f6c7ebc81e63793304
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:35 2012 +0300

    nfsd: pass net to __write_ports() and down

    commit 081603520b25f7b35ef63a363376a17c36ef74ed upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4:
     - adjust context
     - add net_ns parameter to __write_ports_delxprt()]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca0ab0e7c08d41035e1e1e831100dd30aa12dd93
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:30 2012 +0300

    nfsd: pass net to nfsd_set_nrthreads()

    commit 3938a0d5eb5effcc89c6909741403f4e6a37252d upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4: adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8f40af25d332f012cae402bba6f64251d32d09e
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:25 2012 +0300

    nfsd: pass net to nfsd_svc()

    commit d41a9417cd89a69f58a26935034b4264a2d882d6 upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4:
     - adjust context
     - one more parameter(int port) for nfsd_svc()]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfec9be6c092b9b6877fafe50e3d9bdb2f158e89
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:20 2012 +0300

    nfsd: pass net to nfsd_create_serv()

    commit 6777436b0f072fb20a025a73e9b67a35ad8a5451 upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4: adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ef9be17cc1f4dbc54138323918545cd092731d0
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:14 2012 +0300

    nfsd: pass net to nfsd_startup() and nfsd_shutdown()

    commit db42d1a76a8dfcaba7a2dc9c591fa4e231db22b3 upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4:
     - adjust context
     - one more parameter(int port) for nfsd_startup()
     - no net ns initialization in nfsd_shutdown()
     - pass @net to lockd_up() in nfsd_startup()
     - pass @net to lockd_down() in nfsd_shutdown()]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 384015ae656fcd984bb6b33002090e579b37a706
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Dec 10 12:19:09 2012 +0300

    nfsd: pass net to nfsd_init_socks()

    commit db6e182c17cb1a7069f7f8924721ce58ac05d9a3 upstream.

    Precursor patch. Hard-coded "init_net" will be replaced by proper one in
    future.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [wengmeiling: backport to 3.4:
     - adjust context
     - one more parameter(int port) for nfsd_init_socks()
     - net initialization in nfsd_startup()]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3898d0561531795820e76b78cc9072c001754c89
Author: Amit Shah <amit.shah@redhat.com>
Date:   Fri Mar 29 16:30:08 2013 +0530

    virtio: console: add locking around c_ovq operations

    commit 9ba5c80b1aea8648a3efe5f22dc1f7cacdfbeeb8 upstream.

    When multiple ovq operations are being performed (lots of open/close
    operations on virtio_console fds), the __send_control_msg() function can
    get confused without locking.

    A simple recipe to cause badness is:
    * create a QEMU VM with two virtio-serial ports
    * in the guest, do
      while true;do echo abc >/dev/vport0p1;done
      while true;do echo edf >/dev/vport0p2;done

    In one run, this caused a panic in __send_control_msg().  In another, I
    got

       virtio_console virtio0: control-o:id 0 is not a head!

    This also results repeated messages similar to these on the host:

      qemu-kvm: virtio-serial-bus: Unexpected port id 478762112 for device virtio-serial-bus.0
      qemu-kvm: virtio-serial-bus: Unexpected port id 478762368 for device virtio-serial-bus.0

    Reported-by: FuXiangChun <xfu@redhat.com>
    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Reviewed-by: Asias He <asias@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wyj: Backported to 3.4: adjust context]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 666ee13a0e710d0f4d452aa882cae7879580049d
Author: Amit Shah <amit.shah@redhat.com>
Date:   Fri Mar 29 16:30:07 2013 +0530

    virtio: console: rename cvq_lock to c_ivq_lock

    commit 165b1b8bbc17c9469b053bab78b11b7cbce6d161 upstream.

    The cvq_lock was taken for the c_ivq.  Rename the lock to make that
    obvious.

    We'll also add a lock around the c_ovq in the next commit, so there's no
    ambiguity.

    Signed-off-by: Amit Shah <amit.shah@redhat.com>
    Reviewed-by: Asias He <asias@redhat.com>
    Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    [bwh: Backported to 3.2:
     - Adjust context
     - Drop change to virtcons_restore()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wyj: Backported to 3.4:
     - pick change to virtcons_restore() from upsteam patch]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc3f80b9f55b210c9641b75a600dbe79229ca85c
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Fri May 17 10:44:15 2013 +0930

    virtio_console: fix uapi header

    commit 6407d75afd08545f2252bb39806ffd3f10c7faac upstream.

    uapi should use __u32 not u32.
    Fix a macro in virtio_console.h which uses u32.

    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2501e8378946ef828a4ba5084813f2829cc82126
Author: Alexander Graf <agraf@suse.de>
Date:   Wed Jan 2 15:37:17 2013 +1030

    virtio-blk: Don't free ida when disk is in use

    commit f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 upstream.

    When a file system is mounted on a virtio-blk disk, we then remove it
    and then reattach it, the reattached disk gets the same disk name and
    ids as the hot removed one.

    This leads to very nasty effects - mostly rendering the newly attached
    device completely unusable.

    Trying what happens when I do the same thing with a USB device, I saw
    that the sd node simply doesn't get free'd when a device gets forcefully
    removed.

    Imitate the same behavior for vd devices. This way broken vd devices
    simply are never free'd and newly attached ones keep working just fine.

    Signed-off-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da39e19a2ea000eef43edab03ac5bed46afd3190
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Oct 19 14:03:32 2012 +0100

    virtio: 9p: correctly pass physical address to userspace for high pages

    commit 30d395b124c51db66d9f3ba0611cd62021afc392 upstream.

    commit b9cdc88df8e63e81c723b82c286fc97f5d0dc325 upstream.

    When using a virtio transport, the 9p net device may pass the physical
    address of a kernel buffer to userspace via a scatterlist inside a
    virtqueue. If the kernel buffer is mapped outside of the linear mapping
    (e.g. highmem), then virt_to_page will return a bogus value and we will
    populate the scatterlist with junk.

    This patch uses kmap_to_page when populating the page array for a kernel
    buffer.

    Cc: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76a3f516bb9c4597a0ecee20bd3febf79b6e60b5
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Oct 19 14:03:31 2012 +0100

    mm: highmem: export kmap_to_page for modules

    commit f0263d2d222e9e25f2587e51a9dc58c6fb2a9352 upstream.

    Some virtio device drivers (9p) need to translate high virtual addresses
    to physical addresses, which are inserted into the virtqueue for
    processing by userspace.

    This patch exports the kmap_to_page symbol, so that the affected drivers
    can be compiled as modules.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e0e94526767170b7b0fd4c56bfae4be063adbb6
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Jul 31 16:45:02 2012 -0700

    mm: add kmap_to_page()

    commit fcb8996728fb59eddf84678df7cb213b2c9a2e26 upstream.

    This is extracted from Mel Gorman's commit 5a178119b0fb ('mm: add
    support for direct_IO to highmem pages') upstream.

    Required to backport commit b9cdc88df8e6 ('virtio: 9p: correctly pass
    physical address to userspace for high pages').

    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e925ed1e2a85ecb09b79105c569ba7e9aa6c7a78
Author: Asias He <asias@redhat.com>
Date:   Fri May 25 10:34:48 2012 +0800

    virtio-blk: Reset device after blk_cleanup_queue()

    commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream.

    blk_cleanup_queue() will call blk_drian_queue() to drain all the
    requests before queue DEAD marking. If we reset the device before
    blk_cleanup_queue() the drain would fail.

    1) if the queue is stopped in do_virtblk_request() because device is
    full, the q->request_fn() will not be called.

    blk_drain_queue() {
       while(true) {
          ...
          if (!list_empty(&q->queue_head))
            __blk_run_queue(q) {
    	    if (queue is not stoped)
    		q->request_fn()
    	}
          ...
       }
    }

    Do no reset the device before blk_cleanup_queue() gives the chance to
    start the queue in interrupt handler blk_done().

    2) In commit b79d866c8b7014a51f611a64c40546109beaf24a, We abort requests
    dispatched to driver before blk_cleanup_queue(). There is a race if
    requests are dispatched to driver after the abort and before the queue
    DEAD mark. To fix this, instead of aborting the requests explicitly, we
    can just reset the device after after blk_cleanup_queue so that the
    device can complete all the requests before queue DEAD marking in the
    drain process.

    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: virtualization@lists.linux-foundation.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Asias He <asias@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 428369e35e21ee99ed3011219c75190a4f7b92c8
Author: Asias He <asias@redhat.com>
Date:   Fri May 25 10:34:47 2012 +0800

    virtio-blk: Call del_gendisk() before disable guest kick

    commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream.

    del_gendisk() might not return due to failing to remove the
    /sys/block/vda/serial sysfs entry when another thread (udev) is
    trying to read it.

    virtblk_remove()
      vdev->config->reset() : guest will not kick us through interrupt
        del_gendisk()
          device_del()
            kobject_del(): got stuck, sysfs entry ref count non zero

    sysfs_open_file(): user space process read /sys/block/vda/serial
       sysfs_get_active() : got sysfs entry ref count
          dev_attr_show()
            virtblk_serial_show()
               blk_execute_rq() : got stuck, interrupt is disabled
                                  request cannot be finished

    This patch fixes it by calling del_gendisk() before we disable guest's
    interrupt so that the request sent in virtblk_serial_show() will be
    finished and del_gendisk() will success.

    This fixes another race in hot-unplug process.

    It is save to call del_gendisk(vblk->disk) before
    flush_work(&vblk->config_work) which might access vblk->disk, because
    vblk->disk is not freed until put_disk(vblk->disk).

    Cc: virtualization@lists.linux-foundation.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Asias He <asias@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51b69ba68f2b4ab2f675658899b56947e0b904b0
Author: Asias He <asias@redhat.com>
Date:   Fri May 4 20:22:04 2012 +0800

    virtio-blk: Fix hot-unplug race in remove method

    commit b79d866c8b7014a51f611a64c40546109beaf24a upstream.

    If we reset the virtio-blk device before the requests already dispatched
    to the virtio-blk driver from the block layer are finised, we will stuck
    in blk_cleanup_queue() and the remove will fail.

    blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
    before DEAD marking. However it will never success if the device is
    already stopped. We'll have q->in_flight[] > 0, so the drain will not
    finish.

    How to reproduce the race:
    1. hot-plug a virtio-blk device
    2. keep reading/writing the device in guest
    3. hot-unplug while the device is busy serving I/O

    Test:
    ~1000 rounds of hot-plug/hot-unplug test passed with this patch.

    Changes in v3:
    - Drop blk_abort_queue and blk_abort_request
    - Use __blk_end_request_all to complete request dispatched to driver

    Changes in v2:
    - Drop req_in_flight
    - Use virtqueue_detach_unused_buf to get request dispatched to driver

    Signed-off-by: Asias He <asias@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de67686334098b39d18e0d14e8009e75519ad1f1
Author: Asias He <asias@redhat.com>
Date:   Fri Mar 30 11:24:10 2012 +0800

    virtio_blk: Drop unused request tracking list

    commit f65ca1dc6a8c81c6bd72297d4399ec5f4c1f3a01 upstream.

    Benchmark shows small performance improvement on fusion io device.

    Before:
      seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
      seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec
      rnd-read : io=1,024MB, bw=15,404KB/s, iops=30,808, runt= 68070msec
      rnd-write: io=1,024MB, bw=14,776KB/s, iops=29,552, runt= 70963msec

    After:
      seq-read : io=1,024MB, bw=20,343KB/s, iops=40,685, runt= 51546msec
      seq-write: io=1,024MB, bw=20,803KB/s, iops=41,606, runt= 50404msec
      rnd-read : io=1,024MB, bw=16,221KB/s, iops=32,442, runt= 64642msec
      rnd-write: io=1,024MB, bw=15,199KB/s, iops=30,397, runt= 68991msec

    Signed-off-by: Asias He <asias@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 663b3ee86a0124d27e19e26372b2189ab0ab6dd5
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date:   Mon Sep 2 14:57:51 2013 +0300

    Bluetooth: Add support for BCM20702A0 [0b05, 17cb]

    commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.

    Yet another vendor specific ID for this chipset; this one for the ASUS
    USB-BT400 Bluetooth 4.0 adapter.

    T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cb Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=000272C64400
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d239b279829f76260c41a945fa072de19f2169c3
Author: Peng Chen <pengchen@qti.qualcomm.com>
Date:   Fri Aug 30 17:41:40 2013 +0800

    Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.

    commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.

    usb device info:

    T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f34838ca29a4dff225fe90481436c50295700b5d
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Thu Jun 20 13:38:45 2013 +0800

    Bluetooth: Add support for Atheros [0cf3:e003]

    commit 1d5b569ef85d013a775560a90050dc630614c045 upstream.

    Add support for the AR9462 chip

    T:  Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e003 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81ea9a736bf3dfbba4eb4ea0a46b5dbe71bfa6be
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Jul 17 11:27:40 2013 +0800

    Bluetooth: Add support for Atheros [0cf3:3121]

    commit 1ebd0b21ab14efb75950079840eac29afea2a26e upstream.

    Add support for the AR3012 chip.

    T:  Bus=03 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=3121 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a61daa2e05990d9bdca41278f57221028dd80055
Author: Sujith Manoharan <sujith@msujith.org>
Date:   Mon Jul 15 09:29:03 2013 +0530

    Bluetooth: ath3k: Add support for ID 0x13d3/0x3402

    commit 5b77a1f3d7b7360dc2b7c6d2188d39b9f8432907 upstream.

    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3402 Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=59701

    Signed-off-by: Sujith Manoharan <sujith@msujith.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94438c41005869c5dc8fd56a58582d4a3d873fd5
Author: Thomas Loo <tloo@saltstorm.net>
Date:   Wed Jul 3 02:53:54 2013 +0200

    Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]

    commit fb2e4631a7e23c37b9e2e7b2fd776231bbfc39d4 upstream.

    commit 84eb2ae1807dd1467bf6f500fc69ae61f1907b75 upstream.

    The Fujitsu Lifebook UH552/UH572 ships with a Qualcomm AR9462/AR3012
    WLAN/BT-Combo card.
    Add device ID to the ath3k driver to enable the bluetooth side of things.
    Patch against v3.10.

    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04c5 ProdID=1330 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: Thomas Loo <tloo@saltstorm.net>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26cd61a127c90680b74d841dfd8782e4bfeb4fc2
Author: Cho, Yu-Chen <acho@suse.com>
Date:   Tue Jun 4 21:40:26 2013 +0800

    Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]

    commit ff98736cbbbeb9087d4e5d7cb89e05c3e8bd01d6 upstream.

    commit 178c059e7640aa8e50213400c6f3dde00189d979 upstream.

    This patch adds support for Mediatek Bluetooth device

    T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=763f Rev= 1.00
    S:  Manufacturer=MediaTek
    S:  Product=BT
    S:  SerialNumber=1.0
    C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA
    A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:  If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

    Signed-off-by: Cho, Yu-Chen <acho@suse.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47538c6dbaff46a32c7f0acf0a365c5041b7a0e
Author: Noguchi Kazutosi <linux@scaltinof.net>
Date:   Sun Mar 24 23:41:10 2013 +0900

    Bluetooth: Add support for Foxconn/Hon Hai [0489:e04d]

    commit 0fc110f4e4f569e12c472f73f0af485e05631403 upstream.

    Add support for the AR3012 chip.

    T:  Bus=01 Lev=02 Prnt=02 Port=05 Cnt=03 Dev#= 21 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e04d Rev=00.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: Noguchi Kazutosi <linux@scaltinof.net>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd9347cab1282ac03dd3c96c1a72a8be075c09a3
Author: Sunguk Lee <d3m3vilurr@gmail.com>
Date:   Tue Mar 12 04:41:58 2013 +0900

    Bluetooth: Device 0cf3:3008 should map AR 3012

    commit 94a32d10f47b637ae24b78b1ddc7ef0e8396fda4 upstream.

    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=3008 Rev= 0.01
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Sunguk Lee <d3m3vilurr@gmail.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d32bd77dec6f40021e5b43ee1884a4d7812c95a
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Tue Feb 19 11:54:16 2013 -0500

    Bluetooth: Add support for atheros 04ca:3004 device to ath3k

    commit 3f63c340a72f2872a9362245cb2e03f3d2bb73a6 upstream.

    Yet another version of the atheros bluetooth chipset

    T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3004 Rev=00.01
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    This resolves https://bugzilla.redhat.com/show_bug.cgi?id=844750

    Reported-by: niktr@mail.ru
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 251f70cf41961962f33570301ea39a9dd21ed6e8
Author: Sergio Cambra <sergio@programatica.es>
Date:   Thu Jan 10 01:06:55 2013 +0100

    Bluetooth device 04ca:3008 should use ath3k

    commit f4d6f7dce71a5da93da50272ff1670bf2f1146b1 upstream.

    Output of /sys/kernel/debug/usb/devices
    T:  Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  6 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3008 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Sergio Cambra <sergio@programatica.es>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33988445fd446344fe2d20a3e55173ba8af47642
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Thu Jan 3 12:25:00 2013 +0800

    Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]

    commit 2582d529c44d12502a700f1c3db062b9f44679bc upstream.

    Add support for the AR9462 chip

    T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0489 ProdID=e056 Rev=00.01
    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51bd0a4620fa25d1423090eb08043daa5c232ba9
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Thu Jan 3 12:24:59 2013 +0800

    Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]

    commit 3a61eda81ebcfc006ebb1496764299d53e5bf67f upstream.

    Add support for the AR9462 chip

    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e04e Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdb24b4c9464f43c7ac3b7c342b8dbf9ced5ac9a
Author: Daniel Schaal <farbing@web.de>
Date:   Sat Dec 29 11:14:34 2012 +0100

    Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.

    commit 2c262b2a5235b7f5b18d4d58394511f76371d7cb upstream.

    T:  Bus=02 Lev=02 Prnt=02 Port=06 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3006 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Daniel Schaal <farbing@web.de>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cba49fda2aed71e8ae3c6f186674d185cab0ed3
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Tue Dec 11 11:41:20 2012 +0800

    Bluetooth: Add support for IMC Networks [13d3:3393]

    commit eed307e290b96636def331375e065aca43f9069a upstream.

    Add support for the AR9462 chip

    T:  Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3393 Rev=00.01
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3f68bc5e7c6f4d6edacf39d1bcf5cb34a81132
Author: Jeff Cook <jeff@deserettechnology.com>
Date:   Fri Nov 9 16:39:48 2012 -0700

    Bluetooth: Add support for BCM20702A0 [0b05, 17b5]

    commit 1ee3ff6110c16acfc915a79b1e3feb5013c41e75 upstream.

    Vendor-specific ID for BCM20702A0.
    Support for bluetooth over Asus Wi-Fi GO!, included with Asus P8Z77-V
    Deluxe.

    T:  Bus=07 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17b5 Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=94DBC98AC113
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Jeff Cook <jeff@deserettechnology.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85eb3dafd3595c1f968aa9b32f46211a050e5caf
Author: Jaroslav Resler <resler@cs.cas.cz>
Date:   Tue Sep 11 17:25:32 2012 +0800

    Bluetooth: Add support for BCM20702A0 [04ca, 2003]

    commit 0c1abbd1aa0416258881c303a88e618cbca0759c upstream.

    Add another vendor specific ID for BCM20702A0.

    output of usb-devices:
    T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=2003 Rev= 1.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=446D57861623
    C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Cho, Yu-Chen <acho@suse.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a41d97827d332f0d3686f2fbe935d29773770e60
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Wed Aug 15 01:38:11 2012 -0300

    Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn

    commit ee66401bb94b1f2ce51089c341dcdd25d26ae631 upstream.

    Foxconn devices has a vendor specific class of device, we will match them
    differently now.

    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1bf4dbd3a6cd061565e35f6b4f8e84f178df2ee
Author: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
Date:   Tue Aug 7 19:48:10 2012 +0530

    Bluetooth: Add support for Sony Vaio T-Series

    commit bc21fde2d549d1cb1ebef04016eb7affa43bb5c1 upstream.

    Add Sony Vaio T-Series Bluetooth Module( 0x489:0xE036) to
    the blacklist of btusb module and add it to the ath3k module.

    output of cat /sys/kernel/debug/usb/devices

    T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e036 Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73c8edae7705d4137a2d17326bf2605253334dbd
Author: Michael Gruetzner <mgruetzn@gmx.de>
Date:   Wed May 2 22:33:40 2012 +0200

    Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C

    commit 85d59726c5c66016a507f1f4a60db8e374dd284d upstream.

    Add Foxconn/Hon Hai AR5BBU22 Bluetooth Module( 0x489:0xE03C) to
    the blacklist of btusb module and add it to the ath3k module to properly
    load the firmware in Kernel 3.3.4
    The device is integrated in  e.g. some  Acer Aspire 7750G.

    Output from /sys/kernel/debug/usb/devices:

    T:  Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#=  6 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e03c Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Michael Gruetzner <mgruetzn@gmx.de>
    Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e43e4e238ae982166764bdb0db0193adc10ce2
Author: Peng Chen <pengchen@qca.qualcomm.com>
Date:   Wed Aug 1 10:11:59 2012 +0800

    Bluetooth: add support for atheros 0489:e057

    commit 2096ae6ca647302d50a68aa36cb66a00e7dfac70 upstream.

        Add support for the AR3012 chip found on Fioxconn.

        usb-devices shows:

        T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 44 Spd=12   MxCh= 0
        D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
        P:  Vendor=0489 ProdID=e057 Rev= 0.02
        C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
        I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
        E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
        E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
        I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
        I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
        I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
        I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
        I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
        I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f8722c68642252ae4837f2ad55eb950b604b846
Author: Giancarlo Formicuccia <giancarlo.formicuccia@gmail.com>
Date:   Sun Jun 10 08:33:11 2012 +0200

    Bluetooth: add support for atheros 0930:0219

    commit 6c4ae5c2e7bfbb7d10d73611f69ac8a8609d84fd upstream.

    Add support for the AR3012 chip found on the Toshiba Sallite M840-1000-XQ.

    usb-devices shows:

    T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0930 ProdID=0219 Rev=00.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: Giancarlo Formicuccia <giancarlo.formicuccia@gmail.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7387bf2e187c684a76bea8bfcd1c5d0ae9f53d2
Author: Marek Vasut <marex@denx.de>
Date:   Fri Jun 8 14:32:50 2012 +0200

    Bluetooth: Support AR3011 in Acer Iconia Tab W500

    commit 6eda541d12116b4772baa09d3e8d7b0389df4289 upstream.

    Acer used this chip connected via USB:

    Bus 005 Device 005: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               1.10
      bDeviceClass          224 Wireless
      bDeviceSubClass         1 Radio Frequency
      bDeviceProtocol         1 Bluetooth
      bMaxPacketSize0        64
      idVendor           0x0cf3 Atheros Communications, Inc.
      idProduct          0x3005 AR3011 Bluetooth
      bcdDevice            0.01
      iManufacturer           0
      iProduct                0
      iSerial                 0
      bNumConfigurations      1

    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b6afbe29e07b88aac8c377f2a889a55926101e4
Author: Jaganath Kanakkassery <jaganath.k@samsung.com>
Date:   Fri Jun 21 19:55:11 2013 +0530

    Bluetooth: Fix invalid length check in l2cap_information_rsp()

    commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 upstream.

    The length check is invalid since the length varies with type of
    info response.

    This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888

    Because of this, l2cap info rsp is not handled and command reject is sent.

    > ACL data: handle 11 flags 0x02 dlen 16
            L2CAP(s): Info rsp: type 2 result 0
              Extended feature mask 0x00b8
                Enhanced Retransmission mode
                Streaming mode
                FCS Option
                Fixed Channels
    < ACL data: handle 11 flags 0x00 dlen 10
            L2CAP(s): Command rej: reason 0
              Command not understood

    Cc: stable@vger.kernel.org
    Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
    Signed-off-by: Chan-Yeol Park <chanyeol.park@samsung.com>
    Acked-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a625d97010bd6bd1a04a3663637574570f08b32
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Tue May 28 13:46:30 2013 +0300

    Bluetooth: Fix missing length checks for L2CAP signalling PDUs

    commit cb3b3152b2f5939d67005cff841a1ca748b19888 upstream.

    There has been code in place to check that the L2CAP length header
    matches the amount of data received, but many PDU handlers have not been
    checking that the data received actually matches that expected by the
    specific PDU. This patch adds passing the length header to the specific
    handler functions and ensures that those functions fail cleanly in the
    case of an incorrect amount of data.

    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Move uses of *req below the new check in l2cap_connect_req]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4:
     - Adjust context
     - Adjust l2cap_create_channel_rsp()'s parameters]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c888cceb9b256e0497af9e3dc70bd80113c3cdf
Author: Andrey Ryabinin <a.ryabinin@samsung.com>
Date:   Fri Jun 6 19:09:30 2014 +0400

    mm: rmap: fix use-after-free in __put_anon_vma

    commit 624483f3ea82598ab0f62f1bdb9177f531ab1892 upstream.

    While working address sanitizer for kernel I've discovered
    use-after-free bug in __put_anon_vma.

    For the last anon_vma, anon_vma->root freed before child anon_vma.
    Later in anon_vma_free(anon_vma) we are referencing to already freed
    anon_vma->root to check rwsem.

    This fixes it by freeing the child anon_vma before freeing
    anon_vma->root.

    Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83989fe377f92aaf664e7b832432d11391533d6a
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri May 23 10:45:54 2014 -0400

    USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume

    commit 8ef42ddd9a53b73e6fc3934278710c27f80f324f upstream.

    Not all host controller drivers have bus-suspend and bus-resume
    methods.  When one doesn't, it will cause problems if runtime PM is
    enabled in the kernel.  The PM core will attempt to suspend the
    controller's root hub, the suspend will fail because there is no
    bus-suspend routine, and a -EBUSY error code will be returned to the
    PM core.  This will cause the suspend attempt to be repeated shortly
    thereafter, in a never-ending loop.

    Part of the problem is that the original error code -ENOENT gets
    changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM
    core will interpret -ENOENT as meaning that the root hub has gotten
    into a runtime-PM error state.  While this change is appropriate for
    real USB devices, it's not such a good idea for a root hub.  In fact,
    considering the root hub to be in a runtime-PM error state would not
    be far from the truth.  Therefore this patch updates
    usb_runtime_suspend() so that it adjusts error codes only for
    non-root-hub devices.

    Furthermore, the patch attempts to prevent the problem from occurring
    in the first place by not enabling runtime PM by default for root hubs
    whose host controller driver doesn't have bus_suspend and bus_resume
    methods.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Will Deacon <will.deacon@arm.com>
    Tested-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49016dbd14f045392318f934ddf3793c7b4d0136
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sat Apr 26 11:53:44 2014 +0200

    USB: io_ti: fix firmware download on big-endian machines (part 2)

    commit c03890ff5e24a4bf59059f2d179f427559b7330a upstream.

    A recent patch that purported to fix firmware download on big-endian
    machines failed to add the corresponding sparse annotation to the
    i2c-header. This was reported by the kbuild test robot.

    Adding the appropriate annotation revealed another endianess bug related
    to the i2c-header Size-field in a code path that is exercised when the
    firmware is actually being downloaded (and not just verified and left
    untouched unless older than the firmware at hand).

    This patch adds the required sparse annotation to the i2c-header and
    makes sure that the Size-field is sent in little-endian byte order
    during firmware download also on big-endian machines.

    Note that this patch is only compile-tested, but that there is no
    functional change for little-endian systems.

    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Ludovic Drolez <ldrolez@debian.org>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47d48587b6519acd829f4cb946e531b496feec67
Author: Alexej Starschenko <starschenko@gmail.com>
Date:   Wed May 7 10:43:29 2014 +0200

    USB: serial: option: add support for Novatel E371 PCIe card

    commit 8a61ba3a47ac39f660702aa66a172185dd605a86 upstream.

    Adds product ID for the Novatel E371 PCI Express Mini Card.

    $ lsusb
    Bus 001 Device 024: ID 1410:9011 Novatel Wireless

    $ usb-devices
    T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 24 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1410 ProdID=9011 Rev=00.03
    S:  Manufacturer=Novatel Wireless, Inc.
    S:  Product=Novatel Wireless HSPA
    S:  SerialNumber=012773002115811
    C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 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= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
    I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether

    Tested with kernel 3.2.0.

    Signed-off-by: Alexej Starschenko <starschenko@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c30ed57cb739fd3d85651fb9d3d8de3a0cb252b8
Author: George McCollister <george.mccollister@gmail.com>
Date:   Sat Apr 26 12:04:47 2014 +0200

    USB: ftdi_sio: add NovaTech OrionLXm product ID

    commit d0839d757e6294921c31b1c4ca4f1dcc5df63bcd upstream.

    The NovaTech OrionLXm uses an onboard FTDI serial converter for JTAG and
    console access.

    Here is the lsusb output:
    Bus 004 Device 123: ID 0403:7c90 Future Technology Devices
    International, Ltd

    Signed-off-by: George McCollister <george.mccollister@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73f54ca1e96620a0c05385923ae263c422ddfe68
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 2 15:16:07 2014 +0200

    ALSA: hda/realtek - Fix COEF widget NID for ALC260 replacer fixup

    commit 192a98e280e560510a62aca8cfa83b4ae7c095bb upstream.

    The conversion to a fixup table for Replacer model with ALC260 in
    commit 20f7d928 took the wrong widget NID for COEF setups.  Namely,
    NID 0x1a should have been used instead of NID 0x20, which is the
    common node for all Realtek codecs but ALC260.

    Fixes: 20f7d928fa6e ('ALSA: hda/realtek - Replace ALC260 model=replacer with the auto-parser')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea1334d6e1a99ff1398da38734cda84a120f2fa1
Author: Ronan Marquet <ronan.marquet@orange.fr>
Date:   Sun Jun 1 18:38:53 2014 +0200

    ALSA: hda/realtek - Correction of fixup codes for PB V7900 laptop

    commit e30cf2d2bed3aed74a651c64de323ba26e4ff7d0 upstream.

    Correcion of wrong fixup entries add in commit ca8f0424 to replace
    static model quirk for PB V7900 laptop (will model).

    [note: the removal of ALC260_FIXUP_HP_PIN_0F chain is also needed as a
     part of the fix; otherwise the pin is set up wrongly as a headphone,
     and user-space (PulseAudio) may be wrongly trying to detect the jack
     state -- tiwai]

    Fixes: ca8f04247eaa ('ALSA: hda/realtek - Add the fixup codes for ALC260 model=will')
    Signed-off-by: Ronan Marquet <ronan.marquet@orange.fr>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c594fac0b38e0e1caf3ec40598298e8e592b429f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon May 19 00:56:22 2014 +0100

    Staging: speakup: Move pasting into a work item

    commit d7500135802ca55b3f4e01a16544e8b34082f8c3 upstream.

    Input is handled in softirq context, but when pasting we may
    need to sleep.  speakup_paste_selection() currently tries to
    bodge this by busy-waiting if in_atomic(), but that doesn't
    help because the ldisc may also sleep.

    For bonus breakage, speakup_paste_selection() changes the
    state of current, even though it's not running in process
    context.

    Move it into a work item and make sure to cancel it on exit.

    References: https://bugs.debian.org/735202
    References: https://bugs.debian.org/744015
    Reported-by: Paul Gevers <elbrus@debian.org>
    Reported-and-tested-by: Jarek Czekalski <jarekczek@poczta.onet.pl>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bd0346c586b04e4d8ec0ed7f0c42b1b262b6b1e
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed May 28 23:51:13 2014 +0300

    xhci: delete endpoints from bandwidth list before freeing whole device

    commit 5dc2808c4729bf080487e61b80ee04e0fdb12a37 upstream.

    Lists of endpoints are stored for bandwidth calculation for roothub ports.
    Make sure we remove all endpoints from the list before the whole device,
    containing its endpoints list_head stuctures, is freed.

    This used to be done in the wrong order in xhci_mem_cleanup(),
    and triggered an oops in resume from S4 (hibernate).

    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e114f45cdb99bc58b34f87b5cb8cc0a9f98b136
Author: NeilBrown <neilb@suse.de>
Date:   Wed May 28 13:39:23 2014 +1000

    md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync".

    commit 3991b31ea072b070081ca3bfa860a077eda67de5 upstream.

    If mddev->ro is set, md_to_sync will (correctly) abort.
    However in that case MD_RECOVERY_INTR isn't set.

    If a RESHAPE had been requested, then ->finish_reshape() will be
    called and it will think the reshape was successful even though
    nothing happened.

    Normally a resync will not be requested if ->ro is set, but if an
    array is stopped while a reshape is on-going, then when the array is
    started, the reshape will be restarted.  If the array is also set
    read-only at this point, the reshape will instantly appear to success,
    resulting in data corruption.

    Consequently, this patch is suitable for any -stable kernel.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54742b388e72139f611b4c857f5c0bcfb3cf3e2c
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Fri May 16 11:50:42 2014 +0800

    sched: Fix hotplug vs. set_cpus_allowed_ptr()

    commit 6acbfb96976fc3350e30d964acb1dbbdf876d55e upstream.

    Lai found that:

      WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b()
      ...
      migration_cpu_stop+0x1d/0x22

    was caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is
    always a sub-set of cpu_online_mask.

    This isn't true since 5fbd036b552f ("sched: Cleanup cpu_active madness").

    So set active and online at the same time to avoid this particular
    problem.

    Fixes: 5fbd036b552f ("sched: Cleanup cpu_active madness")
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michael wang <wangyun@linux.vnet.ibm.com>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Cc: Toshi Kani <toshi.kani@hp.com>
    Link: http://lkml.kernel.org/r/53758B12.8060609@cn.fujitsu.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2daeb5f024b7387d3e8d7ed16af47d92f093db2
Author: Andrey Ryabinin <a.ryabinin@samsung.com>
Date:   Wed May 7 08:07:25 2014 +0100

    ARM: 8051/1: put_user: fix possible data corruption in put_user

    commit 537094b64b229bf3ad146042f83e74cf6abe59df upstream.

    According to arm procedure call standart r2 register is call-cloberred.
    So after the result of x expression was put into r2 any following
    function call in p may overwrite r2. To fix this, the result of p
    expression must be saved to the temporary variable before the
    assigment x expression to __r2.

    Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36440395e72cb33b030221e46b27461aff864055
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Thu May 22 11:54:21 2014 -0700

    mm/memory-failure.c: fix memory leak by race between poison and unpoison

    commit 3e030ecc0fc7de10fd0da10c1c19939872a31717 upstream.

    When a memory error happens on an in-use page or (free and in-use)
    hugepage, the victim page is isolated with its refcount set to one.

    When you try to unpoison it later, unpoison_memory() calls put_page()
    for it twice in order to bring the page back to free page pool (buddy or
    free hugepage list).  However, if another memory error occurs on the
    page which we are unpoisoning, memory_failure() returns without
    releasing the refcount which was incremented in the same call at first,
    which results in memory leak and unconsistent num_poisoned_pages
    statistics.  This patch fixes it.

    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0219362c94add6318ff39d549cd3491fd6d81752
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri May 2 16:56:01 2014 +0200

    perf: Fix race in removing an event

    commit 46ce0fe97a6be7532ce6126bb26ce89fed81528c upstream.

    When removing a (sibling) event we do:

    	raw_spin_lock_irq(&ctx->lock);
    	perf_group_detach(event);
    	raw_spin_unlock_irq(&ctx->lock);

    	<hole>

    	perf_remove_from_context(event);
    		raw_spin_lock_irq(&ctx->lock);
    		...
    		raw_spin_unlock_irq(&ctx->lock);

    Now, assuming the event is a sibling, it will be 'unreachable' for
    things like ctx_sched_out() because that iterates the
    groups->siblings, and we just unhooked the sibling.

    So, if during <hole> we get ctx_sched_out(), it will miss the event
    and not call event_sched_out() on it, leaving it programmed on the
    PMU.

    The subsequent perf_remove_from_context() call will find the ctx is
    inactive and only call list_del_event() to remove the event from all
    other lists.

    Hereafter we can proceed to free the event; while still programmed!

    Close this hole by moving perf_group_detach() inside the same
    ctx->lock region(s) perf_remove_from_context() has.

    The condition on inherited events only in __perf_event_exit_task() is
    likely complete crap because non-inherited events are part of groups
    too and we're tearing down just the same. But leave that for another
    patch.

    Most-likely-Fixes: e03a9a55b4e ("perf: Change close() semantics for group events")
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Much-staring-at-traces-by: Vince Weaver <vincent.weaver@maine.edu>
    Much-staring-at-traces-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20140505093124.GN17778@laptop.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7862aa42a38b2a81926c1f344afa2b65275f138
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu May 15 20:23:48 2014 +0200

    perf: Limit perf_event_attr::sample_period to 63 bits

    commit 0819b2e30ccb93edf04876237b6205eef84ec8d2 upstream.

    Vince reported that using a large sample_period (one with bit 63 set)
    results in wreckage since while the sample_period is fundamentally
    unsigned (negative periods don't make sense) the way we implement
    things very much rely on signed logic.

    So limit sample_period to 63 bits to avoid tripping over this.

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/n/tip-p25fhunibl4y3qi0zuqmyf4b@git.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb9cf067f0c99c90929252f60fe3c11d3b1484f
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Mon Apr 7 11:04:08 2014 +0200

    perf: Prevent false warning in perf_swevent_add

    commit 39af6b1678afa5880dda7e375cf3f9d395087f6d upstream.

    The perf cpu offline callback takes down all cpu context
    events and releases swhash->swevent_hlist.

    This could race with task context software event being just
    scheduled on this cpu via perf_swevent_add while cpu hotplug
    code already cleaned up event's data.

    The race happens in the gap between the cpu notifier code
    and the cpu being actually taken down. Note that only cpu
    ctx events are terminated in the perf cpu hotplug code.

    It's easily reproduced with:
      $ perf record -e faults perf bench sched pipe

    while putting one of the cpus offline:
      # echo 0 > /sys/devices/system/cpu/cpu1/online

    Console emits following warning:
      WARNING: CPU: 1 PID: 2845 at kernel/events/core.c:5672 perf_swevent_add+0x18d/0x1a0()
      Modules linked in:
      CPU: 1 PID: 2845 Comm: sched-pipe Tainted: G        W    3.14.0+ #256
      Hardware name: Intel Corporation Montevina platform/To be filled by O.E.M., BIOS AMVACRB1.86C.0066.B00.0805070703 05/07/2008
       0000000000000009 ffff880077233ab8 ffffffff81665a23 0000000000200005
       0000000000000000 ffff880077233af8 ffffffff8104732c 0000000000000046
       ffff88007467c800 0000000000000002 ffff88007a9cf2a0 0000000000000001
      Call Trace:
       [<ffffffff81665a23>] dump_stack+0x4f/0x7c
       [<ffffffff8104732c>] warn_slowpath_common+0x8c/0xc0
       [<ffffffff8104737a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff8110fb3d>] perf_swevent_add+0x18d/0x1a0
       [<ffffffff811162ae>] event_sched_in.isra.75+0x9e/0x1f0
       [<ffffffff8111646a>] group_sched_in+0x6a/0x1f0
       [<ffffffff81083dd5>] ? sched_clock_local+0x25/0xa0
       [<ffffffff811167e6>] ctx_sched_in+0x1f6/0x450
       [<ffffffff8111757b>] perf_event_sched_in+0x6b/0xa0
       [<ffffffff81117a4b>] perf_event_context_sched_in+0x7b/0xc0
       [<ffffffff81117ece>] __perf_event_task_sched_in+0x43e/0x460
       [<ffffffff81096f1e>] ? put_lock_stats.isra.18+0xe/0x30
       [<ffffffff8107b3c8>] finish_task_switch+0xb8/0x100
       [<ffffffff8166a7de>] __schedule+0x30e/0xad0
       [<ffffffff81172dd2>] ? pipe_read+0x3e2/0x560
       [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
       [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
       [<ffffffff8166b464>] preempt_schedule_irq+0x44/0x70
       [<ffffffff816707f0>] retint_kernel+0x20/0x30
       [<ffffffff8109e60a>] ? lockdep_sys_exit+0x1a/0x90
       [<ffffffff812a4234>] lockdep_sys_exit_thunk+0x35/0x67
       [<ffffffff81679321>] ? sysret_check+0x5/0x56

    Fixing this by tracking the cpu hotplug state and displaying
    the WARN only if current cpu is initialized properly.

    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1396861448-10097-1-git-send-email-jolsa@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1114e07705417777c1424bed87243d049e4231e
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Sun Apr 13 09:34:53 2014 -0400

    sched: Use CPUPRI_NR_PRIORITIES instead of MAX_RT_PRIO in cpupri check

    commit 6227cb00cc120f9a43ce8313bb0475ddabcb7d01 upstream.

    The check at the beginning of cpupri_find() makes sure that the task_pri
    variable does not exceed the cp->pri_to_cpu array length. But that length
    is CPUPRI_NR_PRIORITIES not MAX_RT_PRIO, where it will miss the last two
    priorities in that array.

    As task_pri is computed from convert_prio() which should never be bigger
    than CPUPRI_NR_PRIORITIES, if the check should cause a panic if it is
    hit.

    Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1397015410.5212.13.camel@marge.simpson.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f31349856222ce8dc18de96e2579d89d2d4d3b93
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jun 7 16:02:54 2014 -0700

    Linux 3.4.92

commit 2bdd48a87d7170dcc1fdb593b21e3e3faf997f50
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:08 2014 +0000

    futex: Make lookup_pi_state more robust

    commit 54a217887a7b658e2650c3feff22756ab80c7339 upstream.

    The current implementation of lookup_pi_state has ambigous handling of
    the TID value 0 in the user space futex.  We can get into the kernel
    even if the TID value is 0, because either there is a stale waiters bit
    or the owner died bit is set or we are called from the requeue_pi path
    or from user space just for fun.

    The current code avoids an explicit sanity check for pid = 0 in case
    that kernel internal state (waiters) are found for the user space
    address.  This can lead to state leakage and worse under some
    circumstances.

    Handle the cases explicit:

           Waiter | pi_state | pi->owner | uTID      | uODIED | ?

      [1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
      [2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

      [3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

      [4]  Found  | Found    | NULL      | 0         | 1      | Valid
      [5]  Found  | Found    | NULL      | >0        | 1      | Invalid

      [6]  Found  | Found    | task      | 0         | 1      | Valid

      [7]  Found  | Found    | NULL      | Any       | 0      | Invalid

      [8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
      [9]  Found  | Found    | task      | 0         | 0      | Invalid
      [10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

     [1] Indicates that the kernel can acquire the futex atomically. We
         came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

     [2] Valid, if TID does not belong to a kernel thread. If no matching
         thread is found then it indicates that the owner TID has died.

     [3] Invalid. The waiter is queued on a non PI futex

     [4] Valid state after exit_robust_list(), which sets the user space
         value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

     [5] The user space value got manipulated between exit_robust_list()
         and exit_pi_state_list()

     [6] Valid state after exit_pi_state_list() which sets the new owner in
         the pi_state but cannot access the user space value.

     [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set.

     [8] Owner and user space value match

     [9] There is no transient state which sets the user space TID to 0
         except exit_robust_list(), but this is indicated by the
         FUTEX_OWNER_DIED bit. See [4]

    [10] There is no transient state which leaves owner and user space
         TID out of sync.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Cc: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a4f162ae0d1b594b897e8d5a977238640c126e2
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:07 2014 +0000

    futex: Always cleanup owner tid in unlock_pi

    commit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e upstream.

    If the owner died bit is set at futex_unlock_pi, we currently do not
    cleanup the user space futex.  So the owner TID of the current owner
    (the unlocker) persists.  That's observable inconsistant state,
    especially when the ownership of the pi state got transferred.

    Clean it up unconditionally.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Cc: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68a24f2298d53b97ea9ead5415f40a2b3dccbf74
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:06 2014 +0000

    futex: Validate atomic acquisition in futex_lock_pi_atomic()

    commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream.

    We need to protect the atomic acquisition in the kernel against rogue
    user space which sets the user space futex to 0, so the kernel side
    acquisition succeeds while there is existing state in the kernel
    associated to the real owner.

    Verify whether the futex has waiters associated with kernel state.  If
    it has, return -EINVAL.  The state is corrupted already, so no point in
    cleaning it up.  Subsequent calls will fail as well.  Not our problem.

    [ tglx: Use futex_top_waiter() and explain why we do not need to try
      	restoring the already corrupted user space state. ]

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8489257df33d5e8fbb1e31d4247ab1e40621df01
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:06 2014 +0000

    futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

    commit e9c243a5a6de0be8e584c604d353412584b592f8 upstream.

    If uaddr == uaddr2, then we have broken the rule of only requeueing from
    a non-pi futex to a pi futex with this call.  If we attempt this, then
    dangling pointers may be left for rt_waiter resulting in an exploitable
    condition.

    This change brings futex_requeue() in line with futex_wait_requeue_pi()
    which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid
    uaddr == uaddr2 in futex_wait_requeue_pi()")

    [ tglx: Compare the resulting keys as well, as uaddrs might be
      	different depending on the mapping ]

    Fixes CVE-2014-3153.

    Reported-by: Pinkie Pie
    Signed-off-by: Will Drewry <wad@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eed2208fb47ed0a13628c91e09800701c41319a
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>
    [gkh: backported to 3.4:
     - adjust context
     - back out bwh's spinlock change]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec310069e55ab86d6307ec03a6fa1360e4f69f3d
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Sep 4 15:10:08 2012 +0100

    dj: memory scribble in logi_dj

    commit 8a55ade76551e3927b4e41ee9e7751875d18bc25 upstream.

    Allocate a structure not a pointer to it !

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Cc: Marc Dionne <marc.c.dionne@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3172d50a89177f97f4913cb19b1607879acb8623
Author: Marc Dionne <marc.c.dionne@gmail.com>
Date:   Fri Jun 1 18:12:14 2012 -0400

    HID: logitech: don't use stack based dj_report structures

    commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407 upstream.

    On a system with a logitech wireless keyboard/mouse and DMA-API debugging
    enabled, this warning appears at boot:

    kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
    kernel: Hardware name: MS-7593
    kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]

    Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode
    use a structure allocated with kzalloc rather than a stack based one.

    Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62fbf398832bcef6e7df6009d9c6315f4e4d5bc0
Author: Joe Lawrence <joe.lawrence@stratus.com>
Date:   Tue Jan 15 15:31:28 2013 -0500

    PCI/ASPM: Don't touch ASPM if forcibly disabled

    commit a26d5ecb3201c11e03663a8f4a7dedc0c5f85c07 upstream.

    Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified
    on the kernel command line.

    Based-on-patch-from: Matthew Garrett <mjg59@srcf.ucam.org>
    Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: David Bulkow <david.bulkow@stratus.com>
    Acked-by: Myron Stowe <myron.stowe@redhat.com>
    [wyj: Backported to 3.4: context adjust]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 652cd61f7c1405deadbb87aa95132bbf899363ed
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Apr 22 02:20:41 2013 +0000

    xen-netfront: reduce gso_max_size to account for max TCP header

    commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream.

    The maximum packet including header that can be handled by netfront / netback
    wire format is 65535. Reduce gso_max_size accordingly.

    Drop skb and print warning when skb->len > 65535. This can 1) save the effort
    to send malformed packet to netback, 2) help spotting misconfiguration of
    netfront in the future.

    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    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>
    [hq: Backported to 3.4: adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23982aa6a77dd457623b3a336bbc5b95f75b0e3b
Author: Joe Perches <joe@perches.com>
Date:   Sun May 13 21:56:25 2012 +0000

    net: Add net_ratelimited_function and net_<level>_ratelimited macros

    commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream.

    __ratelimit() can be considered an inverted bool test because
    it returns true when not ratelimited.  Several tests in the
    kernel tree use this __ratelimit() function incorrectly.

    No net_ratelimit uses are incorrect currently though.

    Most uses of net_ratelimit are to log something via printk or
    pr_<level>.

    In order to minimize the uses of net_ratelimit, and to start
    standardizing the code style used for __ratelimit() and net_ratelimit(),
    add a net_ratelimited_function() macro and net_<level>_ratelimited()
    logging macros similar to pr_<level>_ratelimited that use the global
    net_ratelimit instead of a static per call site "struct ratelimit_state".

    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dd07d71b402ca91edd6ab1c1f28846bb70e2eb6
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Tue Nov 19 17:12:47 2013 +0100

    crypto: s390 - Fix aes-xts parameter corruption

    commit 9dda2769af4f3f3093434648c409bb351120d9e8 upstream.

    Some s390 crypto algorithms incorrectly use the crypto_tfm structure to
    store private data. As the tfm can be shared among multiple threads, this
    can result in data corruption.

    This patch fixes aes-xts by moving the xts and pcc parameter blocks from
    the tfm onto the stack (48 + 96 bytes).

    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 867be22f30d0219441643f7f60d68adfa1419108
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Thu Nov 21 18:03:07 2013 +0100

    can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value

    commit 2fea6cd303c0d0cd9067da31d873b6a6d5bd75e7 upstream.

    This patch fixes the issue that the sja1000_interrupt() function may have
    returned IRQ_NONE without processing the optional pre_irq() and post_irq()
    function before. Further the irq processing counter 'n' is moved to the end of
    the while statement to return correct IRQ_[NONE|HANDLED] values at error
    conditions.

    Reported-by: Wolfgang Grandegger <wg@grandegger.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2: s/SJA1000_IER/REG_IER/; s/SJA1000_IR/REG_IR/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ad03c7a57319469ced8266e5421fba8988387d0
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Nov 12 15:09:39 2013 -0800

    backlight: atmel-pwm-bl: fix gpio polarity in remove

    commit ad5066d4c2b1d696749f8d7816357c23b648c4d3 upstream.

    Make sure to honour gpio polarity also at remove so that the backlight is
    actually disabled on boards with active-low enable pin.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Jingoo Han <jg1.han@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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f530f8b3ac30a9408e8d348497419d739e1f5ba
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Wed Jul 24 18:32:07 2013 -0700

    mtd: m25p80: fix allocation size

    commit 778d226a1462572b51d6777cdb1d611543410cb4 upstream.

    This patch fixes two memory errors:

    1. During a probe failure (in mtd_device_parse_register?) the command
       buffer would not be freed.

    2. The command buffer's size is determined based on the 'fast_read'
       boolean, but the assignment of fast_read is made after this
       allocation. Thus, the buffer may be allocated "too small".

    To fix the first, just switch to the devres version of kzalloc.

    To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
    saving a byte to fiddle around with the conditions here.

    This problem was reported by Yuhang Wang a while back.

    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Reported-by: Yuhang Wang <wangyuhang2014@gmail.com>
    Reviewed-by: Sourav Poddar <sourav.poddar@ti.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56c4364ae352f5f4e59968b26ab7f2ba618e1520
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 5 19:36:27 2013 +0800

    crypto: s390 - Fix aes-cbc IV corruption

    commit f262f0f5cad0c9eca61d1d383e3b67b57dcbe5ea upstream.

    The cbc-aes-s390 algorithm incorrectly places the IV in the tfm
    data structure.  As the tfm is shared between multiple threads,
    this introduces a possibility of data corruption.

    This patch fixes this by moving the parameter block containing
    the IV and key onto the stack (the block is 48 bytes long).

    The same bug exists elsewhere in the s390 crypto system and they
    will be fixed in subsequent patches.

    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e359f920bcc7f408b94b7d7eb141307b770fd4dd
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Sep 17 11:15:43 2013 +0200

    mac80211: drop spoofed packets in ad-hoc mode

    commit 6329b8d917adc077caa60c2447385554130853a3 upstream.

    If an Ad-Hoc node receives packets with the Cell ID or its own MAC
    address as source address, it hits a WARN_ON in sta_info_insert_check()
    With many packets, this can massively spam the logs. One way that this
    can easily happen is through having Cisco APs in the area with rouge AP
    detection and countermeasures enabled.
    Such Cisco APs will regularly send fake beacons, disassoc and deauth
    packets that trigger these warnings.

    To fix this issue, drop such spoofed packets early in the rx path.

    Reported-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: use compare_ether_addr() instead of ether_addr_equal()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f994dfe33b327862837d14a05526745d8774ed
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Thu Jun 20 18:05:56 2013 -0300

    vgacon.c: add cond reschedule points in vgacon_do_font_op

    commit 7e6d72c15ff4cc0c27573901bb05f9eddbd71ed4 upstream.

    Booting a 64-vcpu KVM guest, with CONFIG_PREEMPT_VOLUNTARY,
    can result in a soft lockup:

    BUG: soft lockup - CPU#41 stuck for 67s! [setfont:1505]
     RIP: 0010:[<ffffffff812c48da>]
    [<ffffffff812c48da>] vgacon_do_font_op.clone.0+0x1ba/0x550

    This is due to the 8192 (cmapsz) IO operations taking longer than expected
    due to lock contention in QEMU.

    Add conditional resched points in between writes allowing other tasks to
    execute.

    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: add #include <linux/sched.h>, already present
     upstream]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b21ca109ba78e0bc47bd29340d8b012d38610d6
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Sun Jun 9 18:53:58 2013 +0200

    b43: ensue that BCMA is "y" when B43 is "y"

    commit 693026ef2e751fd94d2e6c71028e68343cc875d5 upstream.

    When b43 gets build into the kernel and it should use bcma we have to
    ensure that bcma was also build into the kernel and not as a module.
    In this patch this is also done for SSB, although you can not
    build b43 without ssb support for now.

    This fixes a build problem reported by Randy Dunlap in
    5187EB95.2060605@infradead.org

    Reported-By: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0764434312978e54dbce56a76fd15d0dee86799
Author: Shane Huang <shane.huang@amd.com>
Date:   Mon Jun 3 18:24:55 2013 +0800

    i2c-piix4: Add AMD CZ SMBus device ID

    commit b996ac90f595dda271cbd858b136b45557fc1a57 upstream.

    To add AMD CZ SMBus controller device ID.

    [bhelgaas: drop pci_ids.h update]
    Signed-off-by: Shane Huang <shane.huang@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Jean Delvare <khali@linux-fr.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93a017f1125569cd1efa36e9e98134aa101d30b2
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 23 18:10:21 2013 +0200

    cfg80211: check wdev->netdev in connection work

    commit c815797663b72e3ac1736f1886538152bc48e4af upstream.

    If a P2P-Device is present and another virtual interface triggers
    the connection work, the system crash because it tries to check
    if the P2P-Device's netdev (which doesn't exist) is up. Skip any
    wdevs that have no netdev to fix this.

    Reported-by: YanBo <dreamfly281@gmail.com>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa60c4aa87f38e1be4e0fdf361f97ae9c91cf93
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri May 24 15:55:33 2013 -0700

    random: fix accounting race condition with lockless irq entropy_count update

    commit 10b3a32d292c21ea5b3ad5ca5975e88bb20b8d68 upstream.

    Commit 902c098a3663 ("random: use lockless techniques in the interrupt
    path") turned IRQ path from being spinlock protected into lockless
    cmpxchg-retry update.

    That commit removed r->lock serialization between crediting entropy bits
    from IRQ context and accounting when extracting entropy on userspace
    read path, but didn't turn the r->entropy_count reads/updates in
    account() to use cmpxchg as well.

    It has been observed, that under certain circumstances this leads to
    read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets
    corrupted and becomes negative, which in turn results in propagating 0
    all the way from account() to the actual read() call.

    Convert the accounting code to be the proper lockless counterpart of
    what has been partially done by 902c098a3663.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Greg KH <greg@kroah.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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ad263543f1e02c4d0e06cdea68f4ed878a1ef36
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jun 2 03:34:36 2013 +0100

    rapidio/tsi721: Fix interrupt mask when handling MSI

    commit 94e0104bca7d6927e85119030b8e6e31fde88a7a upstream.

    Commit 1619f441963e 'rapidio/tsi721: fix bug in MSI interrupt
    handling' (commit 1ccc819da6fd upstream) makes the MSI handler disable
    and re-enable interrupts.  When re-enabling interrupts, we should set
    the same flags as were originally set, but this changed in Linux 3.5 so
    the flags are now inconsistent in 3.2.  In fact, the extra flag isn't
    even defined in 3.2.  Remove the extra flag from the MSI handler.

    Reported-by: Steve Conklin <steve.conklin@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd38dc1416ad0164ca164639010f9badf4c8e017
Author: Alexandre Bounine <alexandre.bounine@idt.com>
Date:   Fri May 24 15:55:17 2013 -0700

    rapidio/tsi721: fix bug in MSI interrupt handling

    commit 1ccc819da6fda9bee10ab8b72e9adbb5ad3e4959 upstream.

    Fix bug in MSI interrupt handling which causes loss of event
    notifications.

    Typical indication of lost MSI interrupts are stalled message and
    doorbell transfers between RapidIO endpoints.  To avoid loss of MSI
    interrupts all interrupts from the device must be disabled on entering
    the interrupt handler routine and re-enabled when exiting it.
    Re-enabling device interrupts will trigger new MSI message(s) if Tsi721
    registered new events since entering interrupt handler routine.

    This patch is applicable to kernel versions starting from v3.2.

    Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15082ff43abcd656eee26c3523b3f7cd2ec9cd37
Author: Maxim Mikityanskiy <maxtram95@gmail.com>
Date:   Sat Dec 15 19:31:31 2012 +0200

    msi-wmi: Fix memory leak

    commit 51c94491c82c3d9029f6e87a1a153db321d88e35 upstream.

    Fix memory leak - don't forget to kfree ACPI object when returning from
    msi_wmi_notify() after suppressing key event.

    Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Acked-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d151ecea9132bc784096ffa659051a038d0c49b8
Author: Jakub Kicinski <jakub.kicinski@intel.com>
Date:   Wed Apr 3 16:50:54 2013 +0000

    ixgbe: fix registration order of driver and DCA nofitication

    commit f01fc1a82c2ee68726b400fadb156bd623b5f2f1 upstream.

    ixgbe_notify_dca cannot be called before driver registration
    because it expects driver's klist_devices to be allocated and
    initialized. While on it make sure debugfs files are removed
    when registration fails.

    Signed-off-by: Jakub Kicinski <jakub.kicinski@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: no debugfs support]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0254a2f597b6bd6e8d0acd0c6f9a5e1428d103a4
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Sun Aug 26 23:35:17 2012 +0200

    speakup: lower default software speech rate

    commit cfd757010691eae4e17acc246f74e7622c3a2f05 upstream.

    Speech synthesis beginners need a low speech rate, and trained people
    want a high speech rate.  A medium speech rate is thus actually not a
    good default for neither.  Since trained people will typically know how
    to change the rate, better default for a low speech rate, which
    beginners can grasp and learn how to increase it afterwards

    This was agreed with users on the speakup mailing list.

    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab1980f778d2fc2a4f4f92ae0012a2bbdc22572b
Author: James Ralston <james.d.ralston@intel.com>
Date:   Thu Aug 9 09:34:20 2012 -0700

    ata_piix: Add Device IDs for Intel Lynx Point-LP PCH

    commit 389cd784969e9148fedcde0608f15bd74d6b769e upstream.

    This patch adds the IDE-mode SATA Device IDs for the Intel Lynx Point-LP PCH

    Signed-off-by: James Ralston <james.d.ralston@intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89c828a73233fb7d48f2e9f64f9ed184cd96121d
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Feb 12 13:46:19 2013 -0800

    drivers/rtc/rtc-pl031.c: restore ST variant functionality

    commit 3399cfb5df9594495b876d1843a7165f77366b2b upstream.

    Commit e7e034e18a0a ("drivers/rtc/rtc-pl031.c: fix the missing operation
    on enable") accidentally broke the ST variants of PL031.

    The bit that is being poked as "clockwatch" enable bit for the ST
    variants does the work of bit 0 on this variant.  Bit 0 is used for a
    clock divider on the ST variants, and setting it to 1 will affect
    timekeeping in a very bad way.

    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Cc: Mian Yousaf KAUKAB <mian.yousaf.kaukab@stericsson.com>
    Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed7b54128b191f06b505e143a0043026a7d26adc
Author: Maia Kozheva <sikon@ubuntu.com>
Date:   Sun Dec 9 16:07:40 2012 +0700

    rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter

    commit fd7b9270120ca7e53fbf0469febe0c68acf6a0a2 upstream.

    D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a
    Ralink chipset supported by the rt2800usb driver. Currently, to work
    around the problem (it's missing in all present kernel versions,
    up to and including 3.7.x), I had to add this to /etc/rc.local:

    echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id

    After that, the device works without problems. Been using it for over
    a week with no bugs in sight.

    The attached patch is trivial and simply adds the new USB ID to the
    list of devices handled by rt2800usb.

    Signed-off-by: Maia Kozheva <sikon@ubuntu.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 904d3b7ff07beb28af432dd5ba6fb87b3e005086
Author: Jaume Delclòs <jaume@delclos.com>
Date:   Fri Nov 2 23:35:20 2012 +0100

    Wireless: rt2x00: Add device id for Sweex LW323 to rt2800usb.c

    commit 36f318bb124b231c01db6965a009f46d5731f012 upstream.

    This patch adds detection for the Sweex LW323 USB wireless network card
    in the rt2x00 driver (just one line in rt2800usb.c).
    It applies to linux-3.7-rc3.

    Signed-off-by: Jaume Delclòs <jaume@delclos.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a5777b063fc8f210cad5ca29b5b91f323985ed1
Author: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date:   Sat Apr 14 23:00:01 2012 +0200

    wireless: rt2x00: rt{2500,73}usb.c put back duplicate id

    commit 8f35f787b75e9b6435ea37dabcae2d40dc72d31c upstream.

    put back 0x050d,0x7050 to rt73usb, same usb_id for two chips:

    K7SF5D7050A ver 2xxx is rt2500
    K7SF5D7050B ver 3xxx is rt73

    <http://en-us-support.belkin.com/app/answers/detail/a_id/297/kw/K7SF5D7050>

    Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ebc8ed06724df2ff611ec75a9231e12002d8b70
Author: Haojian Zhuang <haojian.zhuang@linaro.org>
Date:   Mon Feb 4 14:28:54 2013 -0800

    drivers/rtc/rtc-pl031.c: fix the missing operation on enable

    commit e7e034e18a0ab6bafb2425c3242cac311164f4d6 upstream.

    The RTC control register should be enabled in the process of
    initializing.

    Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC.  The
    register mapping section in RTC is always read as zero.  So I doubt that
    ST guys may already enable this register in bootloader.  So they won't
    meet this issue.

    Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
    Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1938e6bec957eba24fdcc0404bc1b6fa17807324
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sun Aug 4 12:13:17 2013 -0400

    drm/radeon: always program the MC on startup

    commit 6fab3febf6d949b0a12b1e4e73db38e4a177a79e upstream.

    For r6xx+ asics.  This mirrors the behavior of pre-r6xx
    asics.  We need to program the MC even if something
    else in startup() fails.  Failure to do so results in
    an unusable GPU.

    Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [wml: Backported to 3.4:
    - adjust context
    - drop changes to cik.c]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee92bdd30187b3b0d0246b124e7411a805dcf4b4
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 18 09:36:42 2013 -0400

    drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

    commit dcb852905772416e322536ced5cb3c796d176af5 upstream.

    These chips were previously skipped since they are
    pre-R600.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4:
    - adjust context
    - no !ASIC_IS_DCE3(rdev)]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d7e155524ceb423114ee45d44ceea735b1cd611
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Mon Oct 28 02:02:19 2013 -0700

    drm/ttm: Fix memory type compatibility check

    commit 59c8e66378fb78adbcd05f0d09783dde6fef282b upstream.

    Also check the busy placements before deciding to move a buffer object.
    Failing to do this may result in a completely unneccessary move within a
    single memory type.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db261d71868760e1b4971f81efba74aa6cf02f0a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 16 09:49:02 2013 +0100

    drm: Pad drm_mode_get_connector to 64-bit boundary

    commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.

    Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
    the 4 bytes beyond the end of its structure with a 32-bit userspace
    running on a 64-bit kernel. This is due to the padding gcc inserts as
    the drm_mode_get_connector struct includes a u64 and its size is not a
    natural multiple of u64s.

    64-bit kernel:

    sizeof(drm_mode_get_connector)=80, alignof=8
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4

    32-bit userspace:

    sizeof(drm_mode_get_connector)=76, alignof=4
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4

    Fortuituously we can insert explicit padding to the tail of our
    structures without breaking ABI.

    Reported-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37dd860981c94fc74b78619cc4b06abbca2e0495
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 13 18:33:16 2013 -0400

    drm/radeon: fix panel scaling with eDP and LVDS bridges

    commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

    We were using the wrong set_properly callback so we always
    ended up with Full scaling even if something else (Center or
    Full aspect) was selected.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9ea40b8c6d9aed62eb699f238609269de9a852e
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Aug 23 10:50:39 2013 +0300

    drm/i915: try not to lose backlight CBLV precision

    commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream.

    ACPI has _BCM and _BQC methods to set and query the backlight
    brightness, respectively. The ACPI opregion has variables BCLP and CBLV
    to hold the requested and current backlight brightness, respectively.

    The BCLP variable has range 0..255 while the others have range
    0..100. This means the _BCM method has to scale the brightness for BCLP,
    and the gfx driver has to scale the requested value back for CBLV. If
    the _BQC method uses the CBLV variable (apparently some implementations
    do, some don't) for current backlight level reporting, there's room for
    rounding errors.

    Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values
    that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
    255) / 100 for scaling to BCLP.

    Reference: https://gist.github.com/aaronlu/6314920
    Reported-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2:
     - Adjust context
     - ASLE region is treated as normal memory rather than __iomem]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3505269a885f0da4e03ee168fdaa871f49b11a9f
Author: Ondrej Zary <linux@rainbow-software.org>
Date:   Fri Jul 19 21:08:48 2013 +0200

    drm/radeon: Another card with wrong primary dac adj

    commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream.

    Hello,
    got another card with "too bright" problem:
    Sapphire Radeon VE 7000 DDR (VGA+S-Video)

    lspci -vnn:
    01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
            Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]

    The patch below fixes the problem for this card.
    But I don't like the blacklist, couldn't some heuristic be used instead?
    The interesting thing is that the manufacturer is the same as the other card
    needing the same quirk. I wonder how many different types are broken this way.

    The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.

    ====================
    drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR

    Values from BIOS are wrong, causing too bright colors.
    Use default values instead.

    Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d774e15868f50219e0d481780e089b260050698
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 12 15:18:38 2013 +0300

    drm/i915: ensure single initialization and cleanup of backlight device

    commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.

    Backlight cleanup in the eDP connector destroy callback caused the
    backlight device to be removed on some systems that first initialized LVDS
    and then attempted to initialize eDP. Prevent multiple backlight
    initializations, and ensure backlight cleanup is only done once by moving
    it to modeset cleanup.

    A small wrinkle is the introduced asymmetry in backlight
    setup/cleanup. This could be solved by adding refcounting, but it seems
    overkill considering that there should only ever be one backlight device.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: Peter Verthez <peter.verthez@skynet.be>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/dev_priv->backlight\.device/dev_priv->backlight/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ee772fb7fb932bf92b2c588af25ce1c6ed633e7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Apr 4 21:31:03 2013 +0100

    drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

    commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream.

    In order to fully serialize access to the fenced region and the update
    to the fence register we need to take extreme measures on SNB+, and
    manually flush writes to memory prior to writing the fence register in
    conjunction with the memory barriers placed around the register write.

    Fixes i-g-t/gem_fence_thrash

    v2: Bring a bigger gun
    v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
    v4: Remove changes for working generations.
    v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
    v6: Rewrite comments to ellide forgotten history.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jon Bloomfield <jon.bloomfield@intel.com>
    Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2)
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: insert the cache flush in i915_gem_object_get_fence()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faf5157d4726bc12bb6c763a49059fb808e85a5f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Apr 12 19:15:52 2013 -0400

    drm/radeon: cleanup properly if mmio mapping fails

    commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream.

    If we fail to map the mmio BAR, skip driver tear down
    that requires mmio.

    Should fix:
    https://bugzilla.kernel.org/show_bug.cgi?id=56541

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a546b065f6b2fb3b9c8cc5abd4b863d8de2f381f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Apr 1 16:06:25 2013 -0400

    drm/radeon: use frac fb div on RS780/RS880

    commit 411678288d61ba17afe1f8afed92200be6bbc65d upstream.

    Monitors seem to prefer it.  Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=37696

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Add to pll->flags, not radeon_crtc->pll_flags]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faf5c3dbd72d703d596f31921a3195dbf3572592
Author: Egbert Eich <eich@suse.de>
Date:   Sun Oct 14 15:46:38 2012 +0200

    DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.

    commit 5f85f176c2f1c9d2a23f60ca0b99e4d0aa5a26a7 upstream.

    NCR machines with LVDS panels using Intel chipsets need to have the
    QUIRK_INVERT_BRIGHTNESS bit set.
    Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID,
    therefore we add a DMI dependent quirk list.

    Signed-off-by: Egbert Eich <eich@suse.de>
    [danvet: fixup whitespace fail.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Add #include <linux/dmi.h>]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b55a6ae2c2528cdbdd2defd5bba98ed865955e7d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Jan 22 12:50:36 2013 +0200

    drm/i915: add quirk to invert brightness on Packard Bell NCL20

    commit 5559ecadad5a73b27f863e92f4b4f369501dce6f upstream.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
    Reported-by: Alan Zimmerman <alan.zimm@gmail.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4: Adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eff7833f10f7726df80ff4ffcf16bb9447408848
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Jan 22 12:50:35 2013 +0200

    drm/i915: add quirk to invert brightness on eMachines e725

    commit 01e3a8feb40e54b962a20fa7eb595c5efef5e109 upstream.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
    [Note: There are more than one broken setups in the bug. This fixes one.]
    Reported-by: Martins <andrissr@inbox.lv>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4: Adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8186f53d89fb7eb4d1219bcd42dfef724e06771a
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Jan 22 12:50:34 2013 +0200

    drm/i915: add quirk to invert brightness on eMachines G725

    commit 1ffff60320879830e469e26062c18f75236822ba upstream.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
    Reported-by: Roland Gruber <post@rolandgruber.de>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4: Adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e477a84562f5cad0ef4d47f635961cadc940cce8
Author: Carsten Emde <C.Emde@osadl.org>
Date:   Thu Mar 15 15:56:27 2012 +0100

    drm/i915: panel: invert brightness acer aspire 5734z

    commit 5a15ab5b93e4a3ebcd4fa6c76cf646a45e9cf806 upstream.

    Mark the Acer Aspire 5734Z that this machines requires the module to
    invert the panel backlight brightness value after reading from and prior
    to writing to the PCI configuration space.

    Signed-off-by: Carsten Emde <C.Emde@osadl.org>
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4: Adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d47ef924b3c158d6fa5967d4a07017916101248c
Author: Carsten Emde <C.Emde@osadl.org>
Date:   Thu Mar 15 15:56:26 2012 +0100

    drm/i915: panel: invert brightness via quirk

    commit 4dca20efb1a9c2efefc28ad2867e5d6c3f5e1955 upstream.

    A machine may need to invert the panel backlight brightness value. This
    patch adds the infrastructure for a quirk to do so.

    Signed-off-by: Carsten Emde <C.Emde@osadl.org>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wml: Backported to 3.4:
    - Adjust context
    - one more flag QUIRK_NO_PCH_PWM_ENABLE]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cbdce68997a651f5ed0612d0b3593576e158f57
Author: Carsten Emde <C.Emde@osadl.org>
Date:   Thu Mar 15 15:56:25 2012 +0100

    drm/i915: panel: invert brightness via parameter

    commit 7bd90909bbf9ce7c40e1da3d72b97b93839c188a upstream.

    Following the documentation of the Legacy Backlight Brightness (LBB)
    Register in the configuration space of some Intel PCI graphics adapters,
    setting the LBB register with the value 0x0 causes the backlight to be
    turned off, and 0xFF causes the backlight to be set to 100% intensity
    (http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
    The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
    it to maximum intensity at 0. In consequence, the screen of this systems
    becomes dark at an early boot stage which makes it unusable. The same
    inversion applies to the BLC_PWM_CTL I915 register. This problem was
    introduced in kernel version 2.6.38 when the PCI device of this system
    was first supported by the i915 KMS module.

    This patch adds a parameter to the i915 module to enable inversion of
    the brightness variable (i915.invert_brightness).

    Signed-off-by: Carsten Emde <C.Emde@osadl.org>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2aa00ca35df27c0dac7ecf96b4f170c64d315d8
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Feb 14 11:23:35 2013 +0200

    drm/i915: add missing \n to UTS_RELEASE in the error_state

    commit fdfa175d0a9cfa2082ce24e67e284e5acbba452a upstream.

    Amending
    commit 4518f611ba21ba165ea3714055938a8984a44ff9
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Jan 23 16:16:35 2013 +0100

        drm/i915: dump UTS_RELEASE into the error_state

    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ce3daba5141d6652996f36c79bf3085c99b5d2d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state

    commit 4518f611ba21ba165ea3714055938a8984a44ff9 upstream.

    Useful for statistics or on overflowing bug reports to keep things all
    lined up.

    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>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d9b060d78df2c9fccd0e9dbacabe725a436a8db
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jan 2 10:31:22 2013 +0000

    drm/i915; Only increment the user-pin-count after successfully pinning the bo

    commit 93be8788e648817d62fda33e2998eb6ca6ebf3a3 upstream.

    As along the error path we do not correct the user pin-count for the
    failure, we may end up with userspace believing that it has a pinned
    object at offset 0 (when interrupted by a signal for example).

    Signed-off-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>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d0c2593236045b81e30e4d809919f3269515083
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Dec 3 11:36:30 2012 +0000

    drm/i915: Close race between processing unpin task and queueing the flip

    commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream.

    Before queuing the flip but crucially after attaching the unpin-work to
    the crtc, we continue to setup the unpin-work. However, should the
    hardware fire early, we see the connected unpin-work and queue the task.
    The task then promptly runs and unpins the fb before we finish taking
    the required references or even pinning it... Havoc.

    To close the race, we use the flip-pending atomic to indicate when the
    flip is finally setup and enqueued. So during the flip-done processing,
    we can check more accurately whether the flip was expected.

    v2: Add the appropriate mb() to ensure that the writes to the page-flip
    worker are complete prior to marking it active and emitting the MI_FLIP.
    On the read side, the mb should be enforced by the spinlocks.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org
    [danvet: Review the barriers a bit, we need a write barrier both
    before and after updating ->pending. Similarly we need a read barrier
    in the interrupt handler both before and after reading ->pending. With
    well-ordered irqs only one barrier in each place should be required,
    but since this patch explicitly sets out to combat spurious interrupts
    with is staged activation of the unpin work we need to go full-bore on
    the barriers, too. Discussed with Chris Wilson on irc and changes
    acked by him.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [wml: Backported to 3.4: adjust context]
    Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de0c13c617b964543d5a91e2972f5f62f2d75c07
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 5 16:34:58 2012 +0000

    drm/radeon: fix typo in evergreen_mc_resume()

    commit 695ddeb457584a602f2ba117d08ce37cf6ec1589 upstream.

    Add missing index that may have led us to enabling
    more crtcs than necessary.

    May also fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=56139

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76c2ebe89a231aa6a1b23b3ab796489625170006
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Mon Dec 31 03:34:59 2012 +0200

    drm/nouveau: fix init with agpgart-uninorth

    commit eda85d6ad490923152544fba0473798b6cc0edf6 upstream.

    Check that the AGP aperture can be mapped. This follows a similar change
    done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
    the aperture can be mapped by the CPU.).

    The patch fixes the following error seen on G5 iMac:

    	nouveau E[     DRM] failed to create kernel channel, -12

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806
    Reviewed-by: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd6781f6ba37d3fe88eb149cd17bf32ba8a8a18
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 20 16:35:47 2012 -0500

    drm/radeon: add connector table for Mac G4 Silver

    commit cafa59b9011a7790be4ddd5979419259844a165d upstream.

    Apple cards do not provide data tables in the vbios
    so we have to hard code the connector parameters
    in the driver.

    Reported-by: Albrecht Dreß <albrecht.dress@arcor.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5213f5a6483ed29ba7365f88b17a47922c803bd
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 2 12:10:21 2012 -0400

    drm/radeon: add connector table for SAM440ep embedded board

    commit 6a556039e7823d27a0a7f7724d4d455053ea9253 upstream.

    RV250 found on ppc embedded boards.

    Cc: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 748028bc79c57e015495fa7f31074398673930f6
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Dec 11 11:56:52 2012 -0500

    drm/radeon: fix amd afusion gpu setup aka sumo v2

    commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a upstream.

    Set the proper number of tile pipe that should be a multiple of
    pipe depending on the number of se engine.

    Fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=56405
    https://bugs.freedesktop.org/show_bug.cgi?id=56720

    v2: Don't change sumo2

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: don't define/use *_GB_ADDR_CONFIG_GOLDEN]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f639b203067cb595d9ee3a29a0daed6280485c95
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 13 18:03:41 2012 -0500

    drm/radeon/dce32+: use fractional fb dividers for high clocks

    commit a02dc74b317d78298cb0587b9b1f6f741fd5c139 upstream.

    Fixes flickering with some high res montiors.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: use pll->flags instead of radeon_crtc->pll_flags]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e36df9aeeee4d22eb618e72ed4ba51ea59f8064
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 9 17:26:32 2012 +0000

    drm: fix documentation for drm_crtc_set_mode()

    commit 4c9287c6009b37754c42e0ba73a4cc79de92d8f8 upstream.

    x and y parameters are offsets, not width/height

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07d877c82043936a3451155d40b57c293958500a
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Nov 12 18:31:35 2012 +0200

    drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures

    commit d0ddfbd3d1346c1f481ec2289eef350cdba64b42 upstream.

    Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
    left behind ghost connectors, attached (with a dangling pointer) to the
    sdvo that has been cleaned up and freed. Properly destroy any connectors
    attached to the encoder.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
    CC: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: bjo@nord-west.org
    [danvet: added a comment to explain why we need to clean up connectors
    even when sdvo_output_setup fails.]
    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>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 686a77b7b840905b1a5c4214a3cc3700799a3e43
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Jun 18 13:04:23 2013 +0800

    drivers: hv: switch to use mb() instead of smp_mb()

    commit 35848f68b07df3f917cb13fc3c134718669f569b upstream.

    Even if guest were compiled without SMP support, it could not assume that host
    wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for
    UP guest.

    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:
     - Drop changes to functions that don't exist here
     - hv_ringbuffer_write() has only a write memory barrier]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backported to 3.4:
     - Add the change in hv_ringbuffer_read]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 220bba2387420ac4d827a2259f8ef0d00a3b7ce7
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Feb 27 17:05:25 2013 -0800

    nbd: fsync and kill block device on shutdown

    commit 3a2d63f87989e01437ba994df5f297528c353d7d upstream.

    There are two problems with shutdown in the NBD driver.

    1: Receiving the NBD_DISCONNECT ioctl does not sync the filesystem.

       This patch adds the sync operation into __nbd_ioctl()'s
       NBD_DISCONNECT handler.  This is useful because BLKFLSBUF is restricted
       to processes that have CAP_SYS_ADMIN, and the NBD client may not
       possess it (fsync of the block device does not sync the filesystem,
       either).

    2: Once we clear the socket we have no guarantee that later reads will
       come from the same backing storage.

       The patch adds calls to kill_bdev() in __nbd_ioctl()'s socket
       clearing code so the page cache is cleaned, lest reads that hit on the
       page cache will return stale data from the previously-accessible disk.

    Example:

        # qemu-nbd -r -c/dev/nbd0 /dev/sr0
        # file -s /dev/nbd0
        /dev/stdin: # UDF filesystem data (version 1.5) etc.
        # qemu-nbd -d /dev/nbd0
        # qemu-nbd -r -c/dev/nbd0 /dev/sda
        # file -s /dev/nbd0
        /dev/stdin: # UDF filesystem data (version 1.5) etc.

    While /dev/sda has:

        # file -s /dev/sda
        /dev/sda: x86 boot sector; etc.

    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Acked-by: Paul Clements <Paul.Clements@steeleye.com>
    Cc: Alex Bligh <alex@alex.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Adjusted context
     - s/\bnbd\b/lo/
     - Incorporate export of kill_bdev() from commit ff01bb483265
       ('fs: move code out of buffer.c')]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backported to 3.4: Adjusted context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10503ca72262fca708ed9862709686d09da6fa0f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jun 16 21:27:12 2013 +0100

    x86/efi: Fix dummy variable buffer allocation

    commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream.

    1. Check for allocation failure
    2. Clear the buffer contents, as they may actually be written to flash
    3. Don't leak the buffer

    Compile-tested only.

    [ Tested successfully on my buggy ASUS machine - Matt ]

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314b8e108f6cba6d87cd00d294c68da86f0d497c
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date:   Sat Jun 1 16:06:20 2013 -0400

    Modify UEFI anti-bricking code

    commit f8b8404337de4e2466e2e1139ea68b1f8295974f upstream.

    This patch reworks the UEFI anti-bricking code, including an effective
    reversion of cc5a080c and 31ff2f20. It turns out that calling
    QueryVariableInfo() from boot services results in some firmware
    implementations jumping to physical addresses even after entering virtual
    mode, so until we have 1:1 mappings for UEFI runtime space this isn't
    going to work so well.

    Reverting these gets us back to the situation where we'd refuse to create
    variables on some systems because they classify deleted variables as "used"
    until the firmware triggers a garbage collection run, which they won't do
    until they reach a lower threshold. This results in it being impossible to
    install a bootloader, which is unhelpful.

    Feedback from Samsung indicates that the firmware doesn't need more than
    5KB of storage space for its own purposes, so that seems like a reasonable
    threshold. However, there's still no guarantee that a platform will attempt
    garbage collection merely because it drops below this threshold. It seems
    that this is often only triggered if an attempt to write generates a
    genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
    create a variable larger than the remaining space. This should fail, but if
    it somehow succeeds we can then immediately delete it.

    I've tested this on the UEFI machines I have available, but I don't have
    a Samsung and so can't verify that it avoids the bricking problem.

    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [bwh: Backported to 3.2: the reverted changes were never applied here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 799b71fa8787cf54969306e47640b2485e69f9a7
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Apr 17 01:00:53 2013 +0200

    x86,efi: Implement efi_no_storage_paranoia parameter

    commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2 upstream.

    Using this parameter one can disable the storage_size/2 check if
    he is really sure that the UEFI does sane gc and fulfills the spec.

    This parameter is useful if a devices uses more than 50% of the
    storage by default.
    The Intel DQSW67 desktop board is such a sucker for exmaple.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80c49637622f8e7d71482b67e4822672195db25d
Author: Sergey Vlasov <vsu@altlinux.ru>
Date:   Tue Apr 16 18:31:09 2013 +0400

    efi: Export efi_query_variable_store() for efivars.ko

    commit 3668011d4ad556224f7c012c1e870a6eaa0e59da upstream.

    Fixes build with CONFIG_EFI_VARS=m which was broken after the commit
    "x86, efivars: firmware bug workarounds should be in platform code".

    Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6da037a1ec52b0dad6faf93d6a6073fa2437f1a8
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Apr 10 10:59:34 2013 +0200

    x86,efi: Check max_size only if it is non-zero.

    commit 7791c8423f1f7f4dad94e753bae67461d5b80be8 upstream.

    Some EFI implementations return always a MaximumVariableSize of 0,
    check against max_size only if it is non-zero.
    My Intel DQ67SW desktop board has such an implementation.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92d9d665d61ff0562b92db15e33734bee20709ac
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Mon Mar 25 09:14:30 2013 +0000

    x86, efivars: firmware bug workarounds should be in platform code

    commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream.

    Let's not burden ia64 with checks in the common efivars code that we're not
    writing too much data to the variable store. That kind of thing is an x86
    firmware bug, plain and simple.

    efi_query_variable_store() provides platforms with a wrapper in which they can
    perform checks and workarounds for EFI variable storage bugs.

    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80e09c74292736aef9cd8fe7647d8409f82ef652
Author: Seiji Aguchi <seiji.aguchi@hds.com>
Date:   Tue Feb 12 13:04:41 2013 -0800

    efi_pstore: Introducing workqueue updating sysfs

    commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream.

    [Problem]
    efi_pstore creates sysfs entries, which enable users to access to NVRAM,
    in a write callback. If a kernel panic happens in an interrupt context,
    it may fail because it could sleep due to dynamic memory allocations during
    creating sysfs entries.

    [Patch Description]
    This patch removes sysfs operations from a write callback by introducing
    a workqueue updating sysfs entries which is scheduled after the write
    callback is called.

    Also, the workqueue is kicked in a just oops case.
    A system will go down in other cases such as panic, clean shutdown and emergency
    restart. And we don't need to create sysfs entries because there is no chance for
    users to access to them.

    efi_pstore will be robust against a kernel panic in an interrupt context with this patch.

    Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
    Acked-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    [xr: Backported to 3.4:
      - Adjust contest
      - Remove repeated definition of helper function variable_is_present]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5829583ad9ce21eb599c0a3a2b54a4f70224b506
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Mar 22 19:56:51 2013 +0000

    efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE

    commit ca0ba26fbbd2d81c43085df49ce0abfe34535a90 upstream.

    The 'CONFIG_' prefix is not implicit in IS_ENABLED().

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0bf5f68ea9357026018ef47e131feac98f5f2f8
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Mon Mar 11 16:17:50 2013 -0500

    efivars: Add module parameter to disable use as a pstore backend

    commit ec0971ba5372a4dfa753f232449d23a8fd98490e upstream.

    We know that with some firmware implementations writing too much data to
    UEFI variables can lead to bricking machines. Recent changes attempt to
    address this issue, but for some it may still be prudent to avoid
    writing large amounts of data until the solution has been proven on a
    wide variety of hardware.

    Crash dumps or other data from pstore can potentially be a large data
    source. Add a pstore_module parameter to efivars to allow disabling its
    use as a backend for pstore. Also add a config option,
    CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE, to allow setting the default
    value of this paramter to true (i.e. disabled by default).

    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c54934beedf13051c8f531bda88bbd2bd221e9a
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Thu Mar 7 11:40:17 2013 -0600

    efivars: Allow disabling use as a pstore backend

    commit ed9dc8ce7a1c8115dba9483a9b51df8b63a2e0ef upstream.

    Add a new option, CONFIG_EFI_VARS_PSTORE, which can be set to N to
    avoid using efivars as a backend to pstore, as some users may want to
    compile out the code completely.

    Set the default to Y to maintain backwards compatability, since this
    feature has always been enabled until now.

    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 300c5745e9f16aaec1d72a94b96e6eeb040238de
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Mar 23 03:49:53 2013 +0000

    efivars: pstore: Do not check size when erasing variable

    commit 80a19debc2f2d398cfa57fae97bc99826748a602 upstream.

    In 3.2, unlike mainline, efi_pstore_erase() calls efi_pstore_write()
    with a size of 0, as the underlying EFI interface treats a size of 0
    as meaning deletion.

    This was not taken into account in my backport of commit d80a361d779a
    'efi_pstore: Check remaining space with QueryVariableInfo() before
    writing data'.  The size check should be omitted when erasing.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 369a649e2e3e39561638114494ed8f45d4c41471
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Mon Mar 11 17:48:53 2013 -0400

    efi: be more paranoid about available space when creating variables

    commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream.

    UEFI variables are typically stored in flash. For various reasons, avaiable
    space is typically not reclaimed immediately upon the deletion of a
    variable - instead, the system will garbage collect during initialisation
    after a reboot.

    Some systems appear to handle this garbage collection extremely poorly,
    failing if more than 50% of the system flash is in use. This can result in
    the machine refusing to boot. The safest thing to do for the moment is to
    forbid writes if they'd end up using more than half of the storage space.
    We can make this more finegrained later if we come up with a method for
    identifying the broken machines.

    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    [bwh: Backported to 3.2:
     - Drop efivarfs changes and unused check_var_size()
     - Add error codes to include/linux/efi.h, added upstream by
       commit 5d9db883761a ('efi: Add support for a UEFI variable filesystem')
     - Add efi_status_to_err(), added upstream by commit 7253eaba7b17
       ('efivarfs: Return an error if we fail to read a variable')]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf22feafb83e651952e338ebbccaff90cc55c3f2
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Mon Mar 11 17:47:42 2013 -0400

    efivars: Disable external interrupt while holding efivars->lock

    commit 81fa4e581d9283f7992a0d8c534bb141eb840a14 upstream.

    [Problem]
    There is a scenario which efi_pstore fails to log messages in a panic case.

     - CPUA holds an efi_var->lock in either efivarfs parts
       or efi_pstore with interrupt enabled.
     - CPUB panics and sends IPI to CPUA in smp_send_stop().
     - CPUA stops with holding the lock.
     - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
       but it returns without logging messages.

    [Patch Description]
    This patch disables an external interruption while holding efivars->lock
    as follows.

    In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is
    replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may
    be called in an interrupt context.

    In other functions, they are replaced by spin_lock_irq/spin_unlock_irq.
    because they are all called from a process context.

    By applying this patch, we can avoid the problem above with
    a following senario.

     - CPUA holds an efi_var->lock with interrupt disabled.
     - CPUB panics and sends IPI to CPUA in smp_send_stop().
     - CPUA receives the IPI after releasing the lock because it is
       disabling interrupt while holding the lock.
     - CPUB waits for one sec until CPUA releases the lock.
     - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
       And it can hold the lock successfully.

    Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
    Acked-by: Mike Waychison <mikew@google.com>
    Acked-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    [bwh: Backported to 3.2:
     - Drop efivarfs changes
     - Adjust context
     - Drop change to efi_pstore_erase(), which is implemented using
       efi_pstore_write() here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eef751efc441195533ebfc235e67eeecf61ba7dc
Author: Seiji Aguchi <seiji.aguchi@hds.com>
Date:   Wed Nov 14 20:25:37 2012 +0000

    efi_pstore: Check remaining space with QueryVariableInfo() before writing data

    commit d80a361d779a9f19498943d1ca84243209cd5647 upstream.

    [Issue]

    As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario.
    And we wouldn't expect all firmware to handle it gracefully.
    http://marc.info/?l=linux-kernel&m=134305325801789&w=2

    On the other hand, current efi_pstore doesn't check a remaining space of storage at writing time.
    Therefore, efi_pstore may not work if it tries to write a large amount of data.

    [Patch Description]

    To avoid handling the situation above, this patch checks if there is a space enough to log with
    QueryVariableInfo() before writing data.

    Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
    Acked-by: Mike Waychison <mikew@google.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1cb10536f034964738ac9176edbd71f8b81ed45
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Sun Jan 13 20:36:39 2013 -0800

    x86/Sandy Bridge: mark arrays in __init functions as __initconst

    commit 91c90db1aa92a50fa1d7f289502b49ddb46a90d3 upstream.

    commit ab3cd8670e0b3fcde7f029e1503ed3c5138e9571 upstream.

    Mark static arrays as __initconst so they get removed when the init
    sections are flushed.

    Reported-by: Mathias Krause <minipli@googlemail.com>
    Link: http://lkml.kernel.org/r/75F4BEE6-CB0E-4426-B40B-697451677738@googlemail.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45a23bfbc6ab858f48e83e74174f79368ecdfdef
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sat Aug 11 18:06:42 2012 +0200

    ptrace/x86: Partly fix set_task_blockstep()->update_debugctlmsr() logic

    commit 95cf00fa5d5e2a200a2c044c84bde8389a237e02 upstream.

    Afaics the usage of update_debugctlmsr() and TIF_BLOCKSTEP in
    step.c was always very wrong.

    1. update_debugctlmsr() was simply unneeded. The child sleeps
       TASK_TRACED, __switch_to_xtra(next_p => child) should notice
       TIF_BLOCKSTEP and set/clear DEBUGCTLMSR_BTF after resume if
       needed.

    2. It is wrong. The state of DEBUGCTLMSR_BTF bit in CPU register
       should always match the state of current's TIF_BLOCKSTEP bit.

    3. Even get_debugctlmsr() + update_debugctlmsr() itself does not
       look right. Irq can change other bits in MSR_IA32_DEBUGCTLMSR
       register or the caller can be preempted in between.

    4. It is not safe to play with TIF_BLOCKSTEP if task != current.
       DEBUGCTLMSR_BTF and TIF_BLOCKSTEP should always match each
       other if the task is running. The tracee is stopped but it
       can be SIGKILL'ed right before set/clear_tsk_thread_flag().

    However, now that uprobes uses user_enable_single_step(current)
    we can't simply remove update_debugctlmsr(). So this patch adds
    the additional "task == current" check and disables irqs to avoid
    the race with interrupts/preemption.

    Unfortunately this patch doesn't solve the last problem, we need
    another fix. Probably we should teach ptrace_stop() to set/clear
    single/block stepping after resume.

    And afaics there is yet another problem: perf can play with
    MSR_IA32_DEBUGCTLMSR from nmi, this obviously means that even
    __switch_to_xtra() has problems.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016400a085d768fcdfa75f6a802cc19f2f7525da
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Aug 3 17:31:46 2012 +0200

    ptrace/x86: Introduce set_task_blockstep() helper

    commit 848e8f5f0ad3169560c516fff6471be65f76e69f upstream.

    No functional changes, preparation for the next fix and for uprobes
    single-step fixes.

    Move the code playing with TIF_BLOCKSTEP/DEBUGCTLMSR_BTF into the
    new helper, set_task_blockstep().

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74e1e457065d169f46c59c6331ae727a56cee1f3
Author: Radu Caragea <sinaelgl@gmail.com>
Date:   Wed Aug 21 20:55:59 2013 +0300

    x86 get_unmapped_area: Access mmap_legacy_base through mm_struct member

    commit 41aacc1eea645c99edbe8fbcf78a97dc9b862adc upstream.

    This is the updated version of df54d6fa5427 ("x86 get_unmapped_area():
    use proper mmap base for bottom-up direction") that only randomizes the
    mmap base address once.

    Signed-off-by: Radu Caragea <sinaelgl@gmail.com>
    Reported-and-tested-by: Jeff Shorey <shoreyjeff@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Adrian Sendroiu <molecula2788@gmail.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Kamal Mostafa <kamal@canonical.com>
    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>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d47bcef78494369064e8d6ab0c0acd7487314852
Author: Russ Gorby <russ.gorby@intel.com>
Date:   Mon Aug 13 13:45:15 2012 +0100

    n_gsm: replace kfree_skb w/ appropriate dev_* versions

    commit 329e56780e514a7ab607bcb51a52ab0dc2669414 upstream.

    Drivers are supposed to use the dev_* versions of the kfree_skb
    interfaces. In a couple of cases we were called with IRQs
    disabled as well which kfree_skb() does not expect.

    Replaced kfree_skb calls w/ dev_kfree_skb and dev_kfree_skb_any

    Signed-off-by: Russ Gorby <russ.gorby@intel.com>
    Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1eb587c88263772f4884698371d6db24c1325143
Author: Russ Gorby <russ.gorby@intel.com>
Date:   Mon Aug 13 13:44:59 2012 +0100

    n_gsm: avoid accessing freed memory during CMD_FCOFF condition

    commit b4338e1efc339986cf6c0a3652906e914a86e2d3 upstream.

    gsm_data_kick was recently modified to allow messages on the
    tx queue bound for DLCI0 to flow even during FCOFF conditions.
    Unfortunately we introduced a bug discovered by code inspection
    where subsequent list traversers can access freed memory if
    the DLCI0 messages were not all at the head of the list.

    Replaced singly linked tx list w/ a list_head and used
    provided interfaces for traversing and deleting members.

    Signed-off-by: Russ Gorby <russ.gorby@intel.com>
    Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8bac8f9b26765a871c30656cd9c2748505d4ade
Author: samix.lebsir <samix.lebsir@intel.com>
Date:   Mon Aug 13 13:44:22 2012 +0100

    char: n_gsm: remove message filtering for contipated DLCI

    commit 10c6c383e43565c9c6ec07ff8eb2825f8091bdf0 upstream.

    The design of uplink flow control in the mux driver is
    that for constipated channels data will backup into the
    per-channel fifos, and any messages that make it to the
    outbound message queue will still go out.
    Code was added to also stop messages that were in the outbound
    queue but this requires filtering through all the messages on the
    queue for stopped dlcis and changes some of the mux logic unneccessarily.

    The message fiiltering was removed to be in line w/ the original design
    as the message filtering does not provide any solution.
    Extra debug messages used during investigation were also removed.

    Signed-off-by: samix.lebsir <samix.lebsir@intel.com>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 888234366a0832dc826ced151d43ad0f26f78b98
Author: Frederic Berat <fredericx.berat@intel.com>
Date:   Mon Aug 13 13:43:58 2012 +0100

    n_gsm : Flow control handling in Mux driver

    commit c01af4fec2c8f303d6b3354d44308d9e6bef8026 upstream.

    - Correcting handling of FCon/FCoff in order to respect 27.010 spec
    - Consider FCon/off will overide all dlci flow control except for
      dlci0 as we must be able to send control frames.
    - Dlci constipated handling according to FC, RTC and RTR values.
    - Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according
      to dlci constipated value

    Signed-off-by: Frederic Berat <fredericx.berat@intel.com>
    Signed-off-by: Russ Gorby <russ.gorby@intel.com>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efa0d0bdccad10891bedefa7f24f1372a1fc259f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Jun 18 12:33:40 2013 -0700

    x86: fix build error and kconfig for ia32_emulation and binfmt

    commit d1603990ea626668c78527376d9ec084d634202d upstream.

    Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
    when COMPAT_BINFMT_ELF is being selected.

    warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)

    fs/built-in.o: In function `elf_core_dump':
    compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
    compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'

    [ hpa: This was sent to me for -next but it is a low risk build fix ]

    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83975156263ce964ab5641daf2b0e4d04cfe8633
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Wed Oct 23 18:30:12 2013 -0700

    x86/apic: Disable I/O APIC before shutdown of the local APIC

    commit 522e66464467543c0d88d023336eec4df03ad40b upstream.

    In reboot and crash path, when we shut down the local APIC, the I/O APIC is
    still active. This may cause issues because external interrupts
    can still come in and disturb the local APIC during shutdown process.

    To quiet external interrupts, disable I/O APIC before shutdown local APIC.

    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Link: http://lkml.kernel.org/r/1382578212-4677-1-git-send-email-fenghua.yu@intel.com
    [ I suppose the 'issue' is a hang during shutdown. It's a fine change nevertheless. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 638d8fe3b87121ddbfd2c787468266ae8957d099
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Mon Dec 9 15:43:38 2013 -0800

    x86, build: Pass in additional -mno-mmx, -mno-sse options

    commit 8b3b005d675726e38bc504d2e35a991e55819155 upstream.

    In checkin

        5551a34e5aea x86-64, build: Always pass in -mno-sse

    we unconditionally added -mno-sse to the main build, to keep newer
    compilers from generating SSE instructions from autovectorization.
    However, this did not extend to the special environments
    (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
    Add -mno-sse to the compiler command line for these environments, and
    add -mno-mmx to all the environments as well, as we don't want a
    compiler to generate MMX code either.

    This patch also removes a $(cc-option) call for -m32, since we have
    long since stopped supporting compilers too old for the -m32 option,
    and in fact hardcode it in other places in the Makefiles.

    Reported-by: Kevin B. Smith <kevin.b.smith@intel.com>
    Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: H. J. Lu <hjl.tools@gmail.com>
    Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
    [bwh: Backported to 3.2:
     - Drop changes to arch/x86/Makefile, which sets these flags earlier
     - Adjust context
     - Drop changes to arch/x86/realmode/rm/Makefile which doesn't exist]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e20cfb0aa15aa1d650b0644245a094b46b6921af
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Tue Dec 10 14:56:06 2013 -0800

    x86, build, icc: Remove uninitialized_var() from compiler-intel.h

    commit 503cf95c061a0551eb684da364509297efbe55d9 upstream.

    When compiling with icc, <linux/compiler-gcc.h> ends up included
    because the icc environment defines __GNUC__.  Thus, we neither need
    nor want to have this macro defined in both compiler-gcc.h and
    compiler-intel.h, and the fact that they are inconsistent just makes
    the compiler spew warnings.

    Reported-by: Sunil K. Pandey <sunil.k.pandey@intel.com>
    Cc: Kevin B. Smith <kevin.b.smith@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.org
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dfd77f2b1bf017c690406a9fbda871eb97dc10d
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Fri Aug 31 10:02:47 2012 +0200

    tty: serial: imx: don't reinit clock in imx_setup_ufcr()

    commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream.

    Remove the clock configuration from imx_setup_ufcr(). This
    isn't needed here and will cause garbage output if done.

    To be be sure that we only touch the bits we want (TXTL and RXTL)
    we have to mask out all other bits of the UFCR register. Add
    one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6).

    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    CC: Shawn Guo <shawn.guo@linaro.org>
    CC: Sascha Hauer <s.hauer@pengutronix.de>
    CC: Troy Kisky <troy.kisky@boundarydevices.com>
    CC: Xinyu Chen <xinyu.chen@freescale.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: deleted code in imx_setup_ufcr() refers to
     sport->clk not sport->clk_per]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5d92bf233abce8da5cec7a6f97958b513cab343
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 6 18:47:42 2013 +0100

    ALSA: hda - Add support for CX20952

    commit 8f42d7698751a45cd9f7134a5da49bc5b6206179 upstream.

    It's a superset of the existing CX2075x codecs, so we can reuse the
    existing parser code.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1a13c5756c75d09a775efe5ed81531f099009e7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 21 16:53:37 2013 +0100

    ALSA: hda - Add Conexant CX20755/20756/20757 codec IDs

    commit 42c364ace52ae6b4699105b39f2559c256b6cd4c upstream.

    These are just compatible with other CX2075x codecs.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b213e7660ffd2b73d408efcb8dab7841607cd77
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 11 08:39:24 2012 +0200

    ALSA: hda/conexant - Correct vendor IDs for new codecs

    commit 2d825fd82eb765412a558a56e193b77117d56699 upstream.

    Never trust datasheet...

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e84d74ca6e55140829ffff4a97db0ccc624bb24
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 12 12:10:01 2012 +0100

    ALSA: hda - Add stereo-dmic fixup for Acer Aspire One 522

    commit 63a077e27648b4043b1ca1b4e29f0c42d99616b6 upstream.

    Acer Aspire One 522 has the infamous digital mic unit that needs the
    phase inversion fixup for stereo.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27981a1f81dd83404ba3a3aa47601dcdadec903a
Author: Alex Hung <alex.hung@canonical.com>
Date:   Tue Apr 24 16:40:52 2012 +0800

    thinkpad-acpi: fix issuing duplicated key events for brightness up/down

    commit ff413195e830541afeae469fc866ecd0319abd7e upstream.

    The tp_features.bright_acpimode will not be set correctly for brightness
    control because ACPI_VIDEO_HID will not be located in ACPI. As a result,
    a duplicated key event will always be sent. acpi_video_backlight_support()
    is sufficient to detect standard ACPI brightness control.

    Signed-off-by: Alex Hung <alex.hung@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b437de928bc4f1abf3e406db64aec2c7334edce7
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Jan 11 12:21:15 2013 -0700

    PCI: shpchp: Use per-slot workqueues to avoid deadlock

    commit f652e7d2916fe2fcf9e7d709aa5b7476b431e2dd upstream.

    When we have an SHPC-capable bridge with a second SHPC-capable bridge
    below it, pushing the upstream bridge's attention button causes a
    deadlock.

    The deadlock happens because we use the shpchp_wq workqueue to run
    shpchp_pushbutton_thread(), which uses shpchp_disable_slot() to remove
    devices below the upstream bridge.  When we remove the downstream bridge,
    we call shpc_remove(), the shpchp driver's .remove() method.  That calls
    flush_workqueue(shpchp_wq), which deadlocks because the
    shpchp_pushbutton_thread() work item is still running.

    This patch avoids the deadlock by creating a workqueue for every slot
    and removing the single shared workqueue.

    Here's the call path that leads to the deadlock:

      shpchp_queue_pushbutton_work
        queue_work(shpchp_wq)		# shpchp_pushbutton_thread
        ...

      shpchp_pushbutton_thread
        shpchp_disable_slot
          remove_board
            shpchp_unconfigure_device
              pci_stop_and_remove_bus_device
                ...
                  shpc_remove		# shpchp driver .remove method
                    hpc_release_ctlr
                      cleanup_slots
                        flush_workqueue(shpchp_wq)

    This change is based on code inspection, since we don't have hardware
    with this topology.

    Based-on-patch-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backported to 3.4: adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b05d77e413fc3522d3b00a47da9dc5bb207f8620
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Dec 3 12:56:33 2012 +0100

    mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL

    commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream.

    Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending
    failed BAR frames later instead of tearing down aggr" caused regression
    on rt2x00 hardware (connection hangs). This regression was fixed by
    commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let
    mac80211 send a BAR when an AMPDU subframe fails". But the latter
    commit caused yet another problem reported in
    https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22

    After long discussion in this thread:
    http://mid.gmane.org/20121018075615.GA18212@redhat.com
    and testing various alternative solutions, which failed on one or other
    setup, we have no other good fix for the issues like just revert both
    mentioned earlier commits.

    To do not affect other hardware which benefit from commit
    f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it,
    introduce flag that when used will restore mac80211 behaviour before
    the commit.

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    [replaced link with mid.gmane.org that has message-id]
    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>
    [hq: Backported to 3.4: adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a684e653d4fcdc549eda0616029010dc6d3437e
Author: Bruce Allan <bruce.w.allan@intel.com>
Date:   Fri Aug 24 20:38:11 2012 +0000

    e1000e: DoS while TSO enabled caused by link partner with small MSS

    commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

    With a low enough MSS on the link partner and TSO enabled locally, the
    networking stack can periodically send a very large (e.g.  64KB) TCP
    message for which the driver will attempt to use more Tx descriptors than
    are available by default in the Tx ring.  This is due to a workaround in
    the code that imposes a limit of only 4 MSS-sized segments per descriptor
    which appears to be a carry-over from the older e1000 driver and may be
    applicable only to some older PCI or PCIx parts which are not supported in
    e1000e.  When the driver gets a message that is too large to fit across the
    configured number of Tx descriptors, it stops the upper stack from queueing
    any more and gets stuck in this state.  After a timeout, the upper stack
    assumes the adapter is hung and calls the driver to reset it.

    Remove the unnecessary limitation of using up to only 4 MSS-sized segments
    per Tx descriptor, and put in a hard failure test to catch when attempting
    to check for message sizes larger than would fit in the whole Tx ring.
    Refactor the remaining logic that limits the size of data per Tx descriptor
    from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
    Tx packet buffer as described in the hardware specification.

    Also, fix the logic in the check for space in the Tx ring for the next
    largest possible packet after the current one has been successfully queued
    for transmit, and use the appropriate defines for default ring sizes in
    e1000_probe instead of magic values.

    This issue goes back to the introduction of e1000e in 2.6.24 when it was
    split off from e1000.

    Reported-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e4e3a7f4deb64dd17711955f72b96faa3b07f08
Author: Alexander Stein <alexander.stein@systec-electronic.com>
Date:   Thu Dec 13 10:06:10 2012 +0100

    can: c_can: Set reserved bit in IFx_MASK2 to 1 on write

    commit 2bd3bc4e8472424f1a6009825397639a8968920a upstream.

    According to C_CAN documentation, the reserved bit in IFx_MASK2 register is
    fixed 1.

    Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dea15fe0b0dc903eb61e521a6b5262501b383e60
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Jan 16 23:40:01 2013 +0100

    intel_idle: Don't register CPU notifier if we are not running.

    commit 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0 upstream.

    The 'intel_idle_probe' probes the CPU and sets the CPU notifier.
    But if later on during the module initialization we fail (say
    in cpuidle_register_driver), we stop loading, but we neglect
    to unregister the CPU notifier.  This means that during CPU
    hotplug events the system will fail:

    calling  intel_idle_init+0x0/0x326 @ 1
    intel_idle: MWAIT substates: 0x1120
    intel_idle: v0.4 model 0x2A
    intel_idle: lapic_timer_reliable_states 0xffffffff
    intel_idle: intel_idle yielding to none
    initcall intel_idle_init+0x0/0x326 returned -19 after 14 usecs

    ... some time later, offlining and onlining a CPU:

    cpu 3 spinlock event irq 62
    BUG: unable to ] __cpuidle_register_device+0x1c/0x120
    PGD 99b8b067 PUD 99b95067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: xen_evtchn nouveau mxm_wmi wmi radeon ttm i915 fbcon tileblit font atl1c bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
    CPU 0
    Pid: 2302, comm: udevd Not tainted 3.8.0-rc3upstream-00249-g09ad159 #1 MSI MS-7680/H61M-P23 (MS-7680)
    RIP: e030:[<ffffffff814d956c>]  [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120
    RSP: e02b:ffff88009dacfcb8  EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff880105380000 RCX: 000000000000001c
    RDX: 0000000000000000 RSI: 0000000000000055 RDI: ffff880105380000
    RBP: ffff88009dacfce8 R08: ffffffff81a4f048 R09: 0000000000000008
    R10: 0000000000000008 R11: 0000000000000000 R12: ffff880105380000
    R13: 00000000ffffffdd R14: 0000000000000000 R15: ffffffff81a523d0
    FS:  00007f37bd83b7a0(0000) GS:ffff880105200000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 00000000a09ea000 CR4: 0000000000042660
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process udevd (pid: 2302, threadinfo ffff88009dace000, task ffff88009afb47f0)
    Stack:
     ffffffff8107f2d0 ffffffff810c2fb7 ffff88009dacfce8 00000000ffffffea
     ffff880105380000 00000000ffffffdd ffff88009dacfd08 ffffffff814d9882
     0000000000000003 ffff880105380000 ffff88009dacfd28 ffffffff81340afd
    Call Trace:
     [<ffffffff8107f2d0>] ? collect_cpu_info_local+0x30/0x30
     [<ffffffff810c2fb7>] ? __might_sleep+0xe7/0x100
     [<ffffffff814d9882>] cpuidle_register_device+0x32/0x70
     [<ffffffff81340afd>] intel_idle_cpu_init+0xad/0x110
     [<ffffffff81340bc8>] cpu_hotplug_notify+0x68/0x80
     [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70
     [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10
     [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30
     [<ffffffff81652cf7>] _cpu_up+0x103/0x14b
     [<ffffffff81652e18>] cpu_up+0xd9/0xec
     [<ffffffff8164a254>] store_online+0x94/0xd0
     [<ffffffff814122fb>] dev_attr_store+0x1b/0x20
     [<ffffffff81216404>] sysfs_write_file+0xf4/0x170
     [<ffffffff811a1024>] vfs_write+0xb4/0x130
     [<ffffffff811a17ea>] sys_write+0x5a/0xa0
     [<ffffffff816643a9>] system_call_fastpath+0x16/0x1b
    Code: 03 18 00 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 e8 84 08 00 00 <48> 8b 78 08 49 89 c4 e8 f8 7f c1 ff 89 c2 b8 ea ff ff ff 84 d2
    RIP  [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120
     RSP <ffff88009dacfcb8>

    This patch fixes that by moving the CPU notifier registration
    as the last item to be done by the module.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.2: notifier is registered only if we do not have ARAT]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657bb8394c296ca8ddabb57b04a1f8c2c53486e2
Author: Axel Lin <axel.lin@ingics.com>
Date:   Wed Jan 9 19:34:57 2013 +0800

    regulator: max8998: Ensure enough delay time for max8998_set_voltage_buck_time_sel

    commit e8d9897ff064b1683c11c15ea1296a67a45d77b0 upstream.

    commit 81d0a6ae7befb24c06f4aa4856af7f8d1f612171 upstream.

    Use DIV_ROUND_UP to prevent truncation by integer division issue.
    This ensures we return enough delay time.

    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    [bwh: Backported to 3.2: delay is done by driver, not returned to the caller]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 470b636c32ad77767a4193d796c418956c5d0503
Author: Axel Lin <axel.lin@ingics.com>
Date:   Fri Dec 28 17:09:03 2012 +0800

    regulator: max8997: Use uV in voltage_map_desc

    commit bc3b7756b5ff66828acf7bc24f148d28b8d61108 upstream.

    Current code does integer division (min_vol = min_uV / 1000) before pass
    min_vol to max8997_get_voltage_proper_val().
    So it is possible min_vol is truncated to a smaller value.

    For example, if the request min_uV is 800900 for ldo.
    min_vol = 800900 / 1000 = 800 (mV)
    Then max8997_get_voltage_proper_val returns 800 mV for this case which is lower
    than the requested voltage.

    Use uV rather than mV in voltage_map_desc to prevent truncation by integer
    division.

    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - voltage_map_desc also has an n_bits field]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d31977219a43c9a70f3918c2604dce9dab8d35c3
Author: Krzysztof Mazur <krzysiek@podlesie.net>
Date:   Wed Dec 19 11:03:41 2012 +0100

    i915: ensure that VGA plane is disabled

    commit 0fde901f1ddd2ce0e380a6444f1fb7ca555859e9 upstream.

    Some broken systems (like HP nc6120) in some cases, usually after LID
    close/open, enable VGA plane, making display unusable (black screen on LVDS,
    some strange mode on VGA output). We used to disable VGA plane only once at
    startup. Now we also check, if VGA plane is still disabled while changing
    mode, and fix that if something changed it.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
    Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: intel_modeset_setup_hw_state() does not
     exist, so call i915_redisable_vga() directly from intel_lid_notify()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30fb50c24bbc3d9840b5549f4536c0522efcdba0
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Mon Oct 15 21:48:48 2012 -0300

    i82975x_edac: Fix dimm label initialization

    commit 479696840239e0cc43efb3c917bdcad2174d2215 upstream.

    The driver has only 4 hardcoded labels, but allows much more memory.
    Fix it by removing the hardcoded logic, using snprintf() instead.

    [   19.833972] general protection fault: 0000 [#1] SMP
    [   19.837733] Modules linked in: i82975x_edac(+) edac_core firewire_ohci firewire_core crc_itu_t nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm i2c_core
    [   19.837733] CPU 0
    [   19.837733] Pid: 390, comm: udevd Not tainted 3.6.1-1.fc17.x86_64.debug #1 Dell Inc.                 Precision WorkStation 390    /0MY510
    [   19.837733] RIP: 0010:[<ffffffff813463a8>]  [<ffffffff813463a8>] strncpy+0x18/0x30
    [   19.837733] RSP: 0018:ffff880078535b68  EFLAGS: 00010202
    [   19.837733] RAX: ffff880069fa9708 RBX: ffff880078588000 RCX: ffff880069fa9708
    [   19.837733] RDX: 000000000000001f RSI: 5f706f5f63616465 RDI: ffff880069fa9708
    [   19.837733] RBP: ffff880078535b68 R08: ffff880069fa9727 R09: 000000000000fffe
    [   19.837733] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
    [   19.837733] R13: 0000000000000000 R14: ffff880069fa9290 R15: ffff880079624a80
    [   19.837733] FS:  00007f3de01ee840(0000) GS:ffff88007c400000(0000) knlGS:0000000000000000
    [   19.837733] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   19.837733] CR2: 00007f3de00b9000 CR3: 0000000078dbc000 CR4: 00000000000007f0
    [   19.837733] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   19.837733] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [   19.837733] Process udevd (pid: 390, threadinfo ffff880078534000, task ffff880079642450)
    [   19.837733] Stack:
    [   19.837733]  ffff880078535c18 ffffffffa017c6b8 00040000816d627f ffff880079624a88
    [   19.837733]  ffffc90004cd6000 ffff880079624520 ffff88007ac21148 0000000000000000
    [   19.837733]  0000000000000000 0004000000000000 feda000078535bc8 ffffffff810d696d
    [   19.837733] Call Trace:
    [   19.837733]  [<ffffffffa017c6b8>] i82975x_init_one+0x2e6/0x3e6 [i82975x_edac]
    ...

    Fix bug reported at:
    	https://bugzilla.redhat.com/show_bug.cgi?id=848149
    And, very likely:
    	https://bbs.archlinux.org/viewtopic.php?id=148033
    	https://bugzilla.kernel.org/show_bug.cgi?id=47171

    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use csrow->channels[chan].label not csrow->channels[chan]->dimm->label]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d0a8b6cdef5d3fb9827fa76c49f148b862953a4
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Sep 13 16:06:48 2012 +0200

    MISC: hpilo, remove pci_disable_device

    commit bcdee04ea7ae0406ae69094f6df1aacb66a69a0b upstream.

    pci_disable_device(pdev) used to be in pci remove function. But this
    PCI device has two functions with interrupt lines connected to a
    single pin. The other one is a USB host controller. So when we disable
    the PIN there e.g. by rmmod hpilo, the controller stops working. It is
    because the interrupt link is disabled in ACPI since it is not
    refcounted yet. See acpi_pci_link_free_irq called from
    acpi_pci_irq_disable.

    It is not the best solution whatsoever, but as a workaround until the
    ACPI irq link refcounting is sorted out this should fix the reported
    errors.

    References: https://lkml.org/lkml/2008/11/4/535

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Grant Grundler <grundler@parisc-linux.org>
    Cc: Nobin Mathew <nobin.mathew@gmail.com>
    Cc: Robert Hancock <hancockr@shaw.ca>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: David Altobelli <david.altobelli@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 237dc10fff33a063b40584cc9ac218e7b492ca8a
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Mon Aug 27 20:56:54 2012 -0300

    floppy: properly handle failure on add_disk loop

    commit d60e7ec18c3fb2cbf90969ccd42889eb2d03aef9 upstream.

    On floppy initialization, if something failed inside the loop we call
    add_disk, there was no cleanup of previous iterations in the error
    handling.

    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0ffdb59f0e36772d1e931fceb186a0e8574062b
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Fri Sep 28 10:29:21 2012 -0700

    Input: synaptics - adjust threshold for treating position values as negative

    commit 824efd37415961d38821ecbd9694e213fb2e8b32 upstream.

    Commit c039450 (Input: synaptics - handle out of bounds values from the
    hardware) caused any hardware reported values over 7167 to be treated as
    a wrapped-around negative value. It turns out that some firmware uses
    the value 8176 to indicate a finger near the edge of the touchpad whose
    actual position cannot be determined. This value now gets treated as
    negative, which can cause pointer jumps and broken edge scrolling on
    these machines.

    I only know of one touchpad which reports negative values, and this
    hardware never reports any value lower than -8 (i.e. 8184). Moving the
    threshold for treating a value as negative up to 8176 should work fine
    then for any hardware we currently know about, and since we're dealing
    with unspecified behavior it's probably the best we can do. The special
    8176 value is also likely to result in sudden jumps in position, so
    let's also clamp this to the maximum specified value for the axis.

    BugLink: http://bugs.launchpad.net/bugs/1046512
    https://bugzilla.kernel.org/show_bug.cgi?id=46371

    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
    Tested-by: Alan Swanson <swanson@ukfsn.org>
    Tested-by: Arteom <arutemus@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbed70247b54f9cd38321dbb74437bdb81ad4217
Author: Matthieu CASTET <matthieu.castet@parrot.com>
Date:   Wed Aug 22 16:03:46 2012 +0200

    UBI: erase free PEB with bitflip in EC header

    commit 193819cf2e6e395b1e1be2d36785dc5563a6edca upstream.

    Without this patch, these PEB are not scrubbed until we put data in them.
    Bitflip can accumulate latter and we can loose the EC header (but VID header
    should be intact and allow to recover data).

    Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69e8e8fab4827a375e35bfd1aab1d72eac89c160
Author: Rashika Kheria <rashika.kheria@gmail.com>
Date:   Wed Oct 30 18:36:32 2013 +0530

    Staging: zram: Fix access of NULL pointer

    commit 46a51c80216cb891f271ad021f59009f34677499 upstream.

    This patch fixes the bug in reset_store caused by accessing NULL pointer.

    The bdev gets its value from bdget_disk() which could fail when memory
    pressure is severe and hence can return NULL because allocation of
    inode in bdget could fail.

    Hence, this patch introduces a check for bdev to prevent reference to a
    NULL pointer in the later part of the code. It also removes unnecessary
    check of bdev for fsync_bdev().

    Acked-by: Jerome Marchand <jmarchan@redhat.com>
    Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccc425e3c68f6f01b793b758be0f03f5e1da056a
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date:   Sat Jun 22 17:21:00 2013 +0300

    zram: allow request end to coincide with disksize

    commit 75c7caf5a052ffd8db3312fa7864ee2d142890c4 upstream.

    Pass valid_io_request() checks if request end coincides with disksize
    (end equals bound), only fail if we attempt to read beyond the bound.

    mkfs.ext2 produces numerous errors:
    [ 2164.632747] quiet_error: 1 callbacks suppressed
    [ 2164.633260] Buffer I/O error on device zram0, logical block 153599
    [ 2164.633265] lost page write due to I/O error on zram0

    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db038329b190e1b5843d25a5df04df15e0344675
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:26 2013 +0800

    zram: avoid access beyond the zram device

    commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 upstream.

    Function valid_io_request() should verify the entire request are within
    the zram device address range. Otherwise it may cause invalid memory
    access when accessing/modifying zram->meta->table[index] because the
    'index' is out of range. Then it may access non-exist memory, randomly
    modify memory belong to other subsystems, which is hard to track down.

    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69142875ea3009b2f1e0c2983dbf6dab46638a1a
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:24 2013 +0800

    zram: destroy all devices on error recovery path in zram_init()

    commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 upstream.

    On error recovery path of zram_init(), it leaks the zram device object
    causing the failure. So change create_device() to free allocated
    resources on error path.

    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Acked-by: Jerome Marchand <jmarchan@redhat.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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b3214c12ba67003cf069b3e5f2f2d950ffb999e
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Jun 7 00:07:22 2013 +0800

    zram: avoid invalid memory access in zram_exit()

    commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream.

    Memory for zram->disk object may have already been freed after returning
    from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
    to access zram->disk again.

    We can't solve this bug by flipping the order of destroy_device(zram)
    and zram_reset_device(zram), that will cause deadlock issues to the
    zram sysfs handler.

    So fix it by holding an extra reference to zram->disk before calling
    destroy_device(zram).

    Signed-off-by: Jiang Liu <jiang.liu@huawei.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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfa8b1d286e16c0c0d95c128de5592fea4d745ea
Author: Minchan Kim <minchan@kernel.org>
Date:   Wed Jan 30 11:41:39 2013 +0900

    zram: Fix deadlock bug in partial read/write

    commit 7e5a5104c6af709a8d97d5f4711e7c917761d464 upstream.

    Now zram allocates new page with GFP_KERNEL in zram I/O path
    if IO is partial. Unfortunately, It may cause deadlock with
    reclaim path like below.

    write_page from fs
    fs_lock
    allocation(GFP_KERNEL)
    reclaim
    pageout
    				write_page from fs
    				fs_lock <-- deadlock

    This patch fixes it by using GFP_NOIO.  In read path, we
    reorganize code flow so that kmap_atomic is called after the
    GFP_NOIO allocation.

    Acked-by: Jerome Marchand <jmarchand@redhat.com>
    Acked-by: Nitin Gupta <ngupta@vflare.org>
    [ penberg@kernel.org: don't use GFP_ATOMIC ]
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: no reordering is needed in the read path]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6240ac801860a7828b5a6c669cc58359b3ae4b99
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Mar 20 17:21:24 2013 +0000

    dm thin: fix discard corruption

    commit f046f89a99ccfd9408b94c653374ff3065c7edb3 upstream.

    Fix a bug in dm_btree_remove that could leave leaf values with incorrect
    reference counts.  The effect of this was that removal of a shared block
    could result in the space maps thinking the block was no longer used.
    More concretely, if you have a thin device and a snapshot of it, sending
    a discard to a shared region of the thin could corrupt the snapshot.

    Thinp uses a 2-level nested btree to store it's mappings.  This first
    level is indexed by thin device, and the second level by logical
    block.

    Often when we're removing an entry in this mapping tree we need to
    rebalance nodes, which can involve shadowing them, possibly creating a
    copy if the block is shared.  If we do create a copy then children of
    that node need to have their reference counts incremented.  In this
    way reference counts percolate down the tree as shared trees diverge.

    The rebalance functions were incrementing the children at the
    appropriate time, but they were always assuming the children were
    internal nodes.  This meant the leaf values (in our case packed
    block/flags entries) were not being incremented.

    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    [bwh: Backported to 3.2: bump target version numbers from 1.0.1 to 1.0.2]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [xr: Backported to 3.4: bump target version numbers to 1.1.1]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d0b09bbe3b672f999b965388623b980be5e4d68
Author: Shiva Krishna Merla <shivakrishna.merla@netapp.com>
Date:   Wed Oct 30 03:26:38 2013 +0000

    dm mpath: fix race condition between multipath_dtr and pg_init_done

    commit 954a73d5d3073df2231820c718fdd2f18b0fe4c9 upstream.

    Whenever multipath_dtr() is happening we must prevent queueing any
    further path activation work.  Implement this by adding a new
    'pg_init_disabled' flag to the multipath structure that denotes future
    path activation work should be skipped if it is set.  By disabling
    pg_init and then re-enabling in flush_multipath_work() we also avoid the
    potential for pg_init to be initiated while suspending an mpath device.

    Without this patch a race condition exists that may result in a kernel
    panic:

    1) If after pg_init_done() decrements pg_init_in_progress to 0, a call
       to wait_for_pg_init_completion() assumes there are no more pending path
       management commands.
    2) If pg_init_required is set by pg_init_done(), due to retryable
       mode_select errors, then process_queued_ios() will again queue the
       path activation work.
    3) If free_multipath() completes before activate_path() work is called a
       NULL pointer dereference like the following can be seen when
       accessing members of the recently destructed multipath:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
    RIP: 0010:[<ffffffffa003db1b>]  [<ffffffffa003db1b>] activate_path+0x1b/0x30 [dm_multipath]
    [<ffffffff81090ac0>] worker_thread+0x170/0x2a0
    [<ffffffff81096c80>] ? autoremove_wake_function+0x0/0x40

    [switch to disabling pg_init in flush_multipath_work & header edits by Mike Snitzer]
    Signed-off-by: Shiva Krishna Merla <shivakrishna.merla@netapp.com>
    Reviewed-by: Krishnasamy Somasundaram <somasundaram.krishnasamy@netapp.com>
    Tested-by: Speagle Andy <Andy.Speagle@netapp.com>
    Acked-by: Junichi Nomura <j-nomura@ce.jp.nec.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Bump version to 1.3.2 not 1.6.0]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [xr: Backported to 3.4: Adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec44cd21b323e09c09397bbf01b6e9bfed0f4175
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Nov 29 18:13:37 2013 -0500

    dm snapshot: avoid snapshot space leak on crash

    commit 230c83afdd9cd384348475bea1e14b80b3b6b1b8 upstream.

    There is a possible leak of snapshot space in case of crash.

    The reason for space leaking is that chunks in the snapshot device are
    allocated sequentially, but they are finished (and stored in the metadata)
    out of order, depending on the order in which copying finished.

    For example, supposed that the metadata contains the following records
    SUPERBLOCK
    METADATA (blocks 0 ... 250)
    DATA 0
    DATA 1
    DATA 2
    ...
    DATA 250

    Now suppose that you allocate 10 new data blocks 251-260. Suppose that
    copying of these blocks finish out of order (block 260 finished first
    and the block 251 finished last). Now, the snapshot device looks like
    this:
    SUPERBLOCK
    METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
    DATA 0
    DATA 1
    DATA 2
    ...
    DATA 250
    DATA 251
    DATA 252
    DATA 253
    DATA 254
    DATA 255
    METADATA (blocks 255, 254, 253, 252, 251)
    DATA 256
    DATA 257
    DATA 258
    DATA 259
    DATA 260

    Now, if the machine crashes after writing the first metadata block but
    before writing the second metadata block, the space for areas DATA 250-255
    is leaked, it contains no valid data and it will never be used in the
    future.

    This patch makes dm-snapshot complete exceptions in the same order they
    were allocated, thus fixing this bug.

    Note: when backporting this patch to the stable kernel, change the version
    field in the following way:
    * if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
    * if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
      to {1, 10, 2}
    Userspace reads the version to determine if the bug was fixed, so the
    version change is needed.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [xr: Backported to 3.4: adjust version]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6f3bf55314b276be31de19437c3b480e2c0a01a
Author: Harshula Jayasuriya <harshula@redhat.com>
Date:   Tue Jul 23 14:21:35 2013 +1000

    nfsd: nfsd_open: when dentry_open returns an error do not propagate as struct file

    commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 upstream.

    The following call chain:
    ------------------------------------------------------------
    nfs4_get_vfs_file
    - nfsd_open
      - dentry_open
        - do_dentry_open
          - __get_file_write_access
            - get_write_access
              - return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY;
    ------------------------------------------------------------

    can result in the following state:
    ------------------------------------------------------------
    struct nfs4_file {
    ...
      fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0},
      fi_access = {{
          counter = 0x1
        }, {
          counter = 0x0
        }},
    ...
    ------------------------------------------------------------

    1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
    NULL, hence nfsd_open() is called where we get status set to an error
    and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach
    nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented.

    2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
    NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but
    nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented.
    Thus we leave a landmine in the form of the nfs4_file data structure in
    an incorrect state.

    3) Eventually, when __nfs4_file_put_access() is called it finds
    fi_access[O_WRONLY] being non-zero, it decrements it and calls
    nfs4_file_put_fd() which tries to fput -ETXTBSY.
    ------------------------------------------------------------
    ...
         [exception RIP: fput+0x9]
         RIP: ffffffff81177fa9  RSP: ffff88062e365c90  RFLAGS: 00010282
         RAX: ffff880c2b3d99cc  RBX: ffff880c2b3d9978  RCX: 0000000000000002
         RDX: dead000000100101  RSI: 0000000000000001  RDI: ffffffffffffffe6
         RBP: ffff88062e365c90   R8: ffff88041fe797d8   R9: ffff88062e365d58
         R10: 0000000000000008  R11: 0000000000000000  R12: 0000000000000001
         R13: 0000000000000007  R14: 0000000000000000  R15: 0000000000000000
         ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
      #9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd]
     #10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd]
     #11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd]
     #12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd]
     #13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd]
     #14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd]
     #15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd]
     #16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc]
     #17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc]
     #18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd]
     #19 [ffff88062e365ee8] kthread at ffffffff81090886
     #20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a
    ------------------------------------------------------------

    Signed-off-by: Harshula Jayasuriya <harshula@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a5a05b5234fbe93087bed553ba93030d6ad2acb
Author: NeilBrown <neilb@suse.de>
Date:   Thu Sep 27 12:35:21 2012 +1000

    md/raid10: fix "enough" function for detecting if array is failed.

    commit 80b4812407c6b1f66a4f2430e69747a13f010839 upstream.

    The 'enough' function is written to work with 'near' arrays only
    in that is implicitly assumes that the offset from one 'group' of
    devices to the next is the same as the number of copies.
    In reality it is the number of 'near' copies.

    So change it to make this number explicit.

    This bug makes it possible to run arrays without enough drives
    present, which is dangerous.
    It is appropriate for an -stable kernel, but will almost certainly
    need to be modified for some of them.

    Reported-by: Jakub Husák <jakub@gooseman.cz>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: s/geo->/conf->/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eba1b9b4df7bf137285ae312cb5229c4ff324ff8
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 1 22:45:47 2013 +0000

    dm snapshot: add missing module aliases

    commit 23cb21092eb9dcec9d3604b68d95192b79915890 upstream.

    Add module aliases so that autoloading works correctly if the user
    tries to activate "snapshot-origin" or "snapshot-merge" targets.

    Reference: https://bugzilla.redhat.com/889973

    Reported-by: Chao Yang <chyang@redhat.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 269fbce92d22d8cc1f64dce2ff89f9fa74e686e9
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri May 10 14:37:15 2013 +0100

    dm bufio: avoid a possible __vmalloc deadlock

    commit 502624bdad3dba45dfaacaf36b7d83e39e74b2d2 upstream.

    This patch uses memalloc_noio_save to avoid a possible deadlock in
    dm-bufio.  (it could happen only with large block size, at most
    PAGE_SIZE << MAX_ORDER (typically 8MiB).

    __vmalloc doesn't fully respect gfp flags. The specified gfp flags are
    used for allocation of requested pages, structures vmap_area, vmap_block
    and vm_struct and the radix tree nodes.

    However, the kernel pagetables are allocated always with GFP_KERNEL.
    Thus the allocation of pagetables can recurse back to the I/O layer and
    cause a deadlock.

    This patch uses the function memalloc_noio_save to set per-process
    PF_MEMALLOC_NOIO flag and the function memalloc_noio_restore to restore
    it. When this flag is set, all allocations in the process are done with
    implied GFP_NOIO flag, thus the deadlock can't happen.

    This should be backported to stable kernels, but they don't have the
    PF_MEMALLOC_NOIO flag and memalloc_noio_save/memalloc_noio_restore
    functions. So, PF_MEMALLOC should be set and restored instead.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    [bwh: Backported to 3.2 as recommended]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2655c8e45945dbdd1f24ca381557c16f994dac9
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Jan 30 13:04:10 2013 -0500

    NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session

    commit c489ee290bdbbace6bb63ebe6ebd4dd605819495 upstream.

    NFS4ERR_DELAY is a legal reply when we call DESTROY_SESSION. It
    usually means that the server is busy handling an unfinished RPC
    request. Just sleep for a second and then retry.
    We also need to be able to handle the NFS4ERR_BACK_CHAN_BUSY return
    value. If the NFS server has outstanding callbacks, we just want to
    similarly sleep & retry.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98610ef2edceba6b7dcef80c2dba6de590910da0
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Fri Feb 15 16:03:46 2013 -0500

    NFSv4.1: Don't decode skipped layoutgets

    commit 085b7a45c63d3da5be155faab9249a5cab224561 upstream.

    layoutget's prepare hook can call rpc_exit with status = NFS4_OK (0).
    Because of this, nfs4_proc_layoutget can't depend on a 0 status to mean
    that the RPC was successfully sent, received and parsed.

    To fix this, use the result's len member to see if parsing took place.

    This fixes the following OOPS -- calling xdr_init_decode() with a buffer length
    0 doesn't set the stream's 'p' member and ends up using uninitialized memory
    in filelayout_decode_layout.

    BUG: unable to handle kernel paging request at 0000000000008050
    IP: [<ffffffff81282e78>] memcpy+0x18/0x120
    PGD 0
    Oops: 0000 [#1] SMP
    last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0/irq
    CPU 1
    Modules linked in: nfs_layout_nfsv41_files nfs lockd fscache auth_rpcgss nfs_acl autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod ppdev parport_pc parport snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 microcode vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptspi mptscsih mptbase scsi_transport_spi [last unloaded: speedstep_lib]

    Pid: 1665, comm: flush-0:22 Not tainted 2.6.32-356-test-2 #2 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
    RIP: 0010:[<ffffffff81282e78>]  [<ffffffff81282e78>] memcpy+0x18/0x120
    RSP: 0018:ffff88003dfab588  EFLAGS: 00010206
    RAX: ffff88003dc42000 RBX: ffff88003dfab610 RCX: 0000000000000009
    RDX: 000000003f807ff0 RSI: 0000000000008050 RDI: ffff88003dc42000
    RBP: ffff88003dfab5b0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000080 R12: 0000000000000024
    R13: ffff88003dc42000 R14: ffff88003f808030 R15: ffff88003dfab6a0
    FS:  0000000000000000(0000) GS:ffff880003420000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000008050 CR3: 000000003bc92000 CR4: 00000000001407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process flush-0:22 (pid: 1665, threadinfo ffff88003dfaa000, task ffff880037f77540)
    Stack:
    ffffffffa0398ac1 ffff8800397c5940 ffff88003dfab610 ffff88003dfab6a0
    <d> ffff88003dfab5d0 ffff88003dfab680 ffffffffa01c150b ffffea0000d82e70
    <d> 000000508116713b 0000000000000000 0000000000000000 0000000000000000
    Call Trace:
    [<ffffffffa0398ac1>] ? xdr_inline_decode+0xb1/0x120 [sunrpc]
    [<ffffffffa01c150b>] filelayout_decode_layout+0xeb/0x350 [nfs_layout_nfsv41_files]
    [<ffffffffa01c17fc>] filelayout_alloc_lseg+0x8c/0x3c0 [nfs_layout_nfsv41_files]
    [<ffffffff8150e6ce>] ? __wait_on_bit+0x7e/0x90

    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bebbc6dcdb4462612d7a45a05b5b470b6bc9f3c
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Mar 20 12:34:32 2013 -0400

    NFSv4.1: Fix a race in pNFS layoutcommit

    commit a073dbff359f4741013ae4b8395f5364c5e00b48 upstream.

    We need to clear the NFS_LSEG_LAYOUTCOMMIT bits atomically with the
    NFS_INO_LAYOUTCOMMIT bit, otherwise we may end up with situations
    where the two are out of sync.
    The first half of the problem is to ensure that pnfs_layoutcommit_inode
    clears the NFS_LSEG_LAYOUTCOMMIT bit through pnfs_list_write_lseg.
    We still need to keep the reference to those segments until the RPC call
    is finished, so in order to make it clear _where_ those references come
    from, we add a helper pnfs_list_write_lseg_done() that cleans up after
    pnfs_list_write_lseg.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Acked-by: Benny Halevy <bhalevy@tonian.com>
    [bwh: Backported to 3.2: s/pnfs_put_lseg/put_lseg/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed4acad84826acb6b30749b9a903335f1c73287b
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Jul 11 16:30:32 2012 -0400

    NFS: nfs_getaclargs.acl_len is a size_t

    commit 56d08fef2369d5ca9ad2e1fc697f5379fd8af751 upstream.

    Squelch compiler warnings:

    fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’:
    fs/nfs/nfs4proc.c:3811:14: warning: comparison between signed and
    	unsigned integer expressions [-Wsign-compare]
    fs/nfs/nfs4proc.c:3818:15: warning: comparison between signed and
    	unsigned integer expressions [-Wsign-compare]

    Introduced by commit bf118a34 "NFSv4: include bitmap in nfsv4 get
    acl data", Dec 7, 2011.

    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df4993a8799e3711655944f10c23000112b6f0d0
Author: fanchaoting <fanchaoting@cn.fujitsu.com>
Date:   Mon Apr 1 21:07:22 2013 +0800

    nfsd: don't run get_file if nfs4_preprocess_stateid_op return error

    commit b022032e195ffca83d7002d6b84297d796ed443b upstream.

    we should return error status directly when nfs4_preprocess_stateid_op
    return error.

    Signed-off-by: fanchaoting <fanchaoting@cn.fujitsu.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f72c3acb978f3f65792c937996c7c872bbc87ecd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jun 12 10:37:08 2012 +0300

    NFSv4.1: integer overflow in decode_cb_sequence_args()

    commit 0439f31c35d1da0b28988b308ea455e38e6a350d upstream.

    This seems like it could overflow on 32 bits.  Use kmalloc_array() which
    has overflow protection built in.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa340acdd9cde150133b11e6cc99c7d6730eb29b
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Nov 19 17:32:43 2013 -0500

    nfsd4: fix xdr decoding of large non-write compounds

    commit 365da4adebb1c012febf81019ad3dc5bb52e2a13 upstream.

    This fixes a regression from 247500820ebd02ad87525db5d9b199e5b66f6636
    "nfsd4: fix decoding of compounds across page boundaries".  The previous
    code was correct: argp->pagelist is initialized in
    nfs4svc_deocde_compoundargs to rqstp->rq_arg.pages, and is therefore a
    pointer to the page *after* the page we are currently decoding.

    The reason that patch nevertheless fixed a problem with decoding
    compounds containing write was a bug in the write decoding introduced by
    5a80a54d21c96590d013378d8c5f65f879451ab4 "nfsd4: reorganize write
    decoding", after which write decoding no longer adhered to the rule that
    argp->pagelist point to the next page.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [bwh: Backported to 3.2: adjust context; there is only one instance to fix]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 841ae5d906332a620fd459ddc0acbd8a7e4dfe19
Author: Andy Adamson <andros@netapp.com>
Date:   Fri Nov 15 16:36:16 2013 -0500

    NFSv4 wait on recovery for async session errors

    commit 4a82fd7c4e78a1b7a224f9ae8bb7e1fd95f670e0 upstream.

    When the state manager is processing the NFS4CLNT_DELEGRETURN flag, session
    draining is off, but DELEGRETURN can still get a session error.
    The async handler calls nfs4_schedule_session_recovery returns -EAGAIN, and
    the DELEGRETURN done then restarts the RPC task in the prepare state.
    With the state manager still processing the NFS4CLNT_DELEGRETURN flag with
    session draining off, these DELEGRETURNs will cycle with errors filling up the
    session slots.

    This prevents OPEN reclaims (from nfs_delegation_claim_opens) required by the
    NFS4CLNT_DELEGRETURN state manager processing from completing, hanging the
    state manager in the __rpc_wait_for_completion_task in nfs4_run_open_task
    as seen in this kernel thread dump:

    kernel: 4.12.32.53-ma D 0000000000000000     0  3393      2 0x00000000
    kernel: ffff88013995fb60 0000000000000046 ffff880138cc5400 ffff88013a9df140
    kernel: ffff8800000265c0 ffffffff8116eef0 ffff88013fc10080 0000000300000001
    kernel: ffff88013a4ad058 ffff88013995ffd8 000000000000fbc8 ffff88013a4ad058
    kernel: Call Trace:
    kernel: [<ffffffff8116eef0>] ? cache_alloc_refill+0x1c0/0x240
    kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
    kernel: [<ffffffffa0358152>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc]
    kernel: [<ffffffff8152914f>] __wait_on_bit+0x5f/0x90
    kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
    kernel: [<ffffffff815291f8>] out_of_line_wait_on_bit+0x78/0x90
    kernel: [<ffffffff8109b520>] ? wake_bit_function+0x0/0x50
    kernel: [<ffffffffa035810d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc]
    kernel: [<ffffffffa040d44c>] nfs4_run_open_task+0x11c/0x160 [nfs]
    kernel: [<ffffffffa04114e7>] nfs4_open_recover_helper+0x87/0x120 [nfs]
    kernel: [<ffffffffa0411646>] nfs4_open_recover+0xc6/0x150 [nfs]
    kernel: [<ffffffffa040cc6f>] ? nfs4_open_recoverdata_alloc+0x2f/0x60 [nfs]
    kernel: [<ffffffffa0414e1a>] nfs4_open_delegation_recall+0x6a/0xa0 [nfs]
    kernel: [<ffffffffa0424020>] nfs_end_delegation_return+0x120/0x2e0 [nfs]
    kernel: [<ffffffff8109580f>] ? queue_work+0x1f/0x30
    kernel: [<ffffffffa0424347>] nfs_client_return_marked_delegations+0xd7/0x110 [nfs]
    kernel: [<ffffffffa04225d8>] nfs4_run_state_manager+0x548/0x620 [nfs]
    kernel: [<ffffffffa0422090>] ? nfs4_run_state_manager+0x0/0x620 [nfs]
    kernel: [<ffffffff8109b0f6>] kthread+0x96/0xa0
    kernel: [<ffffffff8100c20a>] child_rip+0xa/0x20
    kernel: [<ffffffff8109b060>] ? kthread+0x0/0xa0
    kernel: [<ffffffff8100c200>] ? child_rip+0x0/0x20

    The state manager can not therefore process the DELEGRETURN session errors.
    Change the async handler to wait for recovery on session errors.

    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - There's no restart_call label]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc1f9ce1d8951356dca26998ae76d5f17ee5c7fa
Author: Mateusz Guzik <mguzik@redhat.com>
Date:   Fri Mar 8 16:30:03 2013 +0100

    cifs: delay super block destruction until all cifsFileInfo objects are gone

    commit 24261fc23db950951760d00c188ba63cc756b932 upstream.

    cifsFileInfo objects hold references to dentries and it is possible that
    these will still be around in workqueues when VFS decides to kill super
    block during unmount.

    This results in panics like this one:
    BUG: Dentry ffff88001f5e76c0{i=66b4a,n=1M-2} still in use (1) [unmount of cifs cifs]
    ------------[ cut here ]------------
    kernel BUG at fs/dcache.c:943!
    [..]
    Process umount (pid: 1781, threadinfo ffff88003d6e8000, task ffff880035eeaec0)
    [..]
    Call Trace:
     [<ffffffff811b44f3>] shrink_dcache_for_umount+0x33/0x60
     [<ffffffff8119f7fc>] generic_shutdown_super+0x2c/0xe0
     [<ffffffff8119f946>] kill_anon_super+0x16/0x30
     [<ffffffffa036623a>] cifs_kill_sb+0x1a/0x30 [cifs]
     [<ffffffff8119fcc7>] deactivate_locked_super+0x57/0x80
     [<ffffffff811a085e>] deactivate_super+0x4e/0x70
     [<ffffffff811bb417>] mntput_no_expire+0xd7/0x130
     [<ffffffff811bc30c>] sys_umount+0x9c/0x3c0
     [<ffffffff81657c19>] system_call_fastpath+0x16/0x1b

    Fix this by making each cifsFileInfo object hold a reference to cifs
    super block, which implicitly keeps VFS super block around as well.

    Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Reported-and-Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e98f67ab441981d324459c6d84d3262e243adf38
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 28 14:55:17 2012 -0700

    VFS: make vfs_fstat() use f[get|put]_light()

    commit e994defb7b6813ba6fa7a2a36e86d2455ad1dc35 upstream.

    Use the *_light() versions that properly avoid doing the file user count
    updates when they are unnecessary.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [xr: Backported to 3.4: adjust function name]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7f029d1fe6233c60863c0fc2d2b2b44e3c5f859
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Mar 14 14:20:54 2013 -0400

    tracing: Keep overwrite in sync between regular and snapshot buffers

    commit 80902822658aab18330569587cdb69ac1dfdcea8 upstream.

    Changing the overwrite mode for the ring buffer via the trace
    option only sets the normal buffer. But the snapshot buffer could
    swap with it, and then the snapshot would be in non overwrite mode
    and the normal buffer would be in overwrite mode, even though the
    option flag states otherwise.

    Keep the two buffers overwrite modes in sync.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 468deb2b1b39a989fae86adb33312e85f91b11e8
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Apr 12 11:05:54 2013 +0800

    perf: Fix error return code

    commit c481420248c6730246d2a1b1773d5d7007ae0835 upstream.

    Fix to return -ENOMEM in the allocation error case instead of 0
    (if pmu_bus_running == 1), as done elsewhere in this function.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Cc: a.p.zijlstra@chello.nl
    Cc: paulus@samba.org
    Cc: acme@ghostprotocols.net
    Link: http://lkml.kernel.org/r/CAPgLHd8j_fWcgqe%3DKLWjpBj%2B%3Do0Pw6Z-SEq%3DNTPU08c2w1tngQ@mail.gmail.com
    [ Tweaked the error code setting placement and the changelog. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed2907aa78061deaad5ed86033ec1802f5ead8fb
Author: libin <huawei.libin@huawei.com>
Date:   Mon Apr 8 14:39:12 2013 +0800

    sched/debug: Fix sd->*_idx limit range avoiding overflow

    commit fd9b86d37a600488dbd80fe60cca46b822bff1cd upstream.

    Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on
    sysctl") was an incomplete bug fix.

    This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1]
    avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX
    on sysctl.

    Signed-off-by: Libin <huawei.libin@huawei.com>
    Cc: <jiang.liu@huawei.com>
    Cc: <guohanjun@huawei.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/51626610.2040607@huawei.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f0aba0485379b43123fc40d87464a6fdb550138
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Thu Aug 16 17:03:24 2012 +0900

    sched/debug: Limit sd->*_idx range on sysctl

    commit 201c373e8e4823700d3160d5c28e1ab18fd1193e upstream.

    Various sd->*_idx's are used for refering the rq's load average table
    when selecting a cpu to run.  However they can be set to any number
    with sysctl knobs so that it can crash the kernel if something bad is
    given. Fix it by limiting them into the actual range.

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1345104204-8317-1-git-send-email-namhyung@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdcff698e2fa4e7be8a14391826f48457c506ba7
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Tue Jul 30 00:04:32 2013 -0400

    ftrace: Check module functions being traced on reload

    commit 8c4f3c3fa9681dc549cd35419b259496082fef8b upstream.

    There's been a nasty bug that would show up and not give much info.
    The bug displayed the following warning:

     WARNING: at kernel/trace/ftrace.c:1529 __ftrace_hash_rec_update+0x1e3/0x230()
     Pid: 20903, comm: bash Tainted: G           O 3.6.11+ #38405.trunk
     Call Trace:
      [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0
      [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20
      [<ffffffff810c2ee3>] __ftrace_hash_rec_update+0x1e3/0x230
      [<ffffffff810c4f28>] ftrace_hash_move+0x28/0x1d0
      [<ffffffff811401cc>] ? kfree+0x2c/0x110
      [<ffffffff810c68ee>] ftrace_regex_release+0x8e/0x150
      [<ffffffff81149f1e>] __fput+0xae/0x220
      [<ffffffff8114a09e>] ____fput+0xe/0x10
      [<ffffffff8105fa22>] task_work_run+0x72/0x90
      [<ffffffff810028ec>] do_notify_resume+0x6c/0xc0
      [<ffffffff8126596e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
      [<ffffffff815c0f88>] int_signal+0x12/0x17
     ---[ end trace 793179526ee09b2c ]---

    It was finally narrowed down to unloading a module that was being traced.

    It was actually more than that. When functions are being traced, there's
    a table of all functions that have a ref count of the number of active
    tracers attached to that function. When a function trace callback is
    registered to a function, the function's record ref count is incremented.
    When it is unregistered, the function's record ref count is decremented.
    If an inconsistency is detected (ref count goes below zero) the above
    warning is shown and the function tracing is permanently disabled until
    reboot.

    The ftrace callback ops holds a hash of functions that it filters on
    (and/or filters off). If the hash is empty, the default means to filter
    all functions (for the filter_hash) or to disable no functions (for the
    notrace_hash).

    When a module is unloaded, it frees the function records that represent
    the module functions. These records exist on their own pages, that is
    function records for one module will not exist on the same page as
    function records for other modules or even the core kernel.

    Now when a module unloads, the records that represents its functions are
    freed. When the module is loaded again, the records are recreated with
    a default ref count of zero (unless there's a callback that traces all
    functions, then they will also be traced, and the ref count will be
    incremented).

    The problem is that if an ftrace callback hash includes functions of the
    module being unloaded, those hash entries will not be removed. If the
    module is reloaded in the same location, the hash entries still point
    to the functions of the module but the module's ref counts do not reflect
    that.

    With the help of Steve and Joern, we found a reproducer:

     Using uinput module and uinput_release function.

     cd /sys/kernel/debug/tracing
     modprobe uinput
     echo uinput_release > set_ftrace_filter
     echo function > current_tracer
     rmmod uinput
     modprobe uinput
     # check /proc/modules to see if loaded in same addr, otherwise try again
     echo nop > current_tracer

     [BOOM]

    The above loads the uinput module, which creates a table of functions that
    can be traced within the module.

    We add uinput_release to the filter_hash to trace just that function.

    Enable function tracincg, which increments the ref count of the record
    associated to uinput_release.

    Remove uinput, which frees the records including the one that represents
    uinput_release.

    Load the uinput module again (and make sure it's at the same address).
    This recreates the function records all with a ref count of zero,
    including uinput_release.

    Disable function tracing, which will decrement the ref count for uinput_release
    which is now zero because of the module removal and reload, and we have
    a mismatch (below zero ref count).

    The solution is to check all currently tracing ftrace callbacks to see if any
    are tracing any of the module's functions when a module is loaded (it already does
    that with callbacks that trace all functions). If a callback happens to have
    a module function being traced, it increments that records ref count and starts
    tracing that function.

    There may be a strange side effect with this, where tracing module functions
    on unload and then reloading a new module may have that new module's functions
    being traced. This may be something that confuses the user, but it's not
    a big deal. Another approach is to disable all callback hashes on module unload,
    but this leaves some ftrace callbacks that may not be registered, but can
    still have hashes tracing the module's function where ftrace doesn't know about
    it. That situation can cause the same bug. This solution solves that case too.
    Another benefit of this solution, is it is possible to trace a module's
    function on unload and load.

    Link: http://lkml.kernel.org/r/20130705142629.GA325@redhat.com

    Reported-by: Jörn Engel <joern@logfs.org>
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Steve Hodgson <steve@purestorage.com>
    Tested-by: Steve Hodgson <steve@purestorage.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8c0e704820b6774ee2750883e4ffb8f7ef8c1b5
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Oct 28 13:55:29 2013 +0100

    perf: Fix perf ring buffer memory ordering

    commit bf378d341e4873ed928dc3c636252e6895a21f50 upstream.

    The PPC64 people noticed a missing memory barrier and crufty old
    comments in the perf ring buffer code. So update all the comments and
    add the missing barrier.

    When the architecture implements local_t using atomic_long_t there
    will be double barriers issued; but short of introducing more
    conditional barrier primitives this is the best we can do.

    Reported-by: Victor Kaplansky <victork@il.ibm.com>
    Tested-by: Victor Kaplansky <victork@il.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
    Cc: michael@ellerman.id.au
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Michael Neuling <mikey@neuling.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: anton@samba.org
    Cc: benh@kernel.crashing.org
    Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74bf490e9ed4a8dc308feb8debaeb8a1f3aff98b
Author: Justin Lecher <jlec@gentoo.org>
Date:   Mon Jul 30 14:42:53 2012 -0700

    fs: cachefiles: add support for large files in filesystem caching

    commit 98c350cda2c14a343d34ea01a3d9c24fea5ec66d upstream.

    Support the caching of large files.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=31182

    Signed-off-by: Justin Lecher <jlec@gentoo.org>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.com>
    Tested-by: Suresh Jayaraman <sjayaraman@suse.com>
    Acked-by: David Howells <dhowells@redhat.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
     - dentry_open() takes dentry and vfsmount pointers, not a path pointer]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e3b9434145657e12a6e30397f55151a983c6116
Author: Geyslan G. Bem <geyslan@gmail.com>
Date:   Fri Oct 11 16:49:16 2013 -0300

    ecryptfs: Fix memory leakage in keystore.c

    commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream.

    In 'decrypt_pki_encrypted_session_key' function:

    Initializes 'payload' pointer and releases it on exit.

    Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59570dadd9999ea4a5b594b0d9f72ec79b35c73d
Author: Pavel Shilovsky <pshilovsky@etersoft.ru>
Date:   Wed Aug 29 21:13:38 2012 +0400

    CIFS: Fix error handling in cifs_push_mandatory_locks

    commit e2f2886a824ff0a56da1eaa13019fde86aa89fa6 upstream.

    Signed-off-by: Pavel Shilovsky <pshilovsky@etersoft.ru>
    Signed-off-by: Steve French <smfrench@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c32f106f16d6733563b3ec04fa1e0b133b34447b
Author: Steve French <smfrench@gmail.com>
Date:   Fri Nov 15 20:41:32 2013 -0600

    setfacl removes part of ACL when setting POSIX ACLs to Samba

    commit b1d93356427be6f050dc55c86eb019d173700af6 upstream.

    setfacl over cifs mounts can remove the default ACL when setting the
    (non-default part of) the ACL and vice versa (we were leaving at 0
    rather than setting to -1 the count field for the unaffected
    half of the ACL.  For example notice the setfacl removed
    the default ACL in this sequence:

    steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir ; setfacl
    -m default:user:test:rwx,user:test:rwx /mnt/test-dir
    getfacl: Removing leading '/' from absolute path names
    user::rwx
    group::r-x
    other::r-x
    default:user::rwx
    default:user:test:rwx
    default:group::r-x
    default:mask::rwx
    default:other::r-x

    steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir
    getfacl: Removing leading '/' from absolute path names
    user::rwx
    user:test:rwx
    group::r-x
    mask::rwx
    other::r-x

    Signed-off-by: Steve French <smfrench@gmail.com>
    Acked-by: Jeremy Allison <jra@samba.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5ab03319b861c0684c55ce940b5dbba6ca4d03f
Author: Horia Geanta <horia.geanta@freescale.com>
Date:   Fri Apr 18 13:01:42 2014 +0300

    crypto: caam - add allocation failure handling in SPRINTFCAT macro

    commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream.

    GFP_ATOMIC memory allocation could fail.
    In this case, avoid NULL pointer dereference and notify user.

    Cc: Kim Phillips <kim.phillips@freescale.com>
    Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4581ef2b498e4f08dea6b48527b88782abd31be9
Author: Du, Wenkai <wenkai.du@intel.com>
Date:   Thu Apr 10 23:03:19 2014 +0000

    i2c: designware: Mask all interrupts during i2c controller enable

    commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream.

    There have been "i2c_designware 80860F41:00: controller timed out" errors
    on a number of Baytrail platforms. The issue is caused by incorrect value in
    Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
    This causes call to __i2c_dw_enable() to immediately start the transfer which
    leads to timeout. There are 3 failure modes observed:

    1. Failure in S0 to S3 resume path

    The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
    the first transaction after resuming from system sleep, TX_EMPTY interrupt
    is already unmasked because of the hardware default.

    2. Failure in normal operational path

    This failure happens rarely and is hard to reproduce. Debug trace showed that
    DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
    TX_EMPTY was unmasked.

    3. Failure in S3 to S0 suspend path

    This failure also happens rarely and is hard to reproduce. Adding debug trace
    that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
    call trace we could conclude TX_EMPTY was unmasked when problem occurred.

    The patch masks all interrupts before the controller is enabled to resolve the
    faulty DW_IC_INTR_MASK conditions.

    Signed-off-by: Wenkai Du <wenkai.du@intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    [wsa: improved the comment and removed typo in commit msg]
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c65a684c361cf15e54970d11e52d9637bc97a86a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 5 11:38:09 2014 +0200

    ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX

    commit f6e6e1b9fee88c90586787b71dc49bb3ce62bb89 upstream.

    Without this this EEE PC exports a non working WMI interface, with this it
    exports a working "good old" eeepc_laptop interface, fixing brightness control
    not working as well as rfkill being stuck in a permanent wireless blocked
    state.

    This is not an ideal way to fix this, but various attempts to fix this
    otherwise have failed, see:

    References: https://bugzilla.redhat.com/show_bug.cgi?id=1067181
    Reported-and-tested-by: lou.cardone@gmail.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11c15f58957f9f92c3003f80a0941c9ca0c32cce
Author: Marcel Apfelbaum <marcel.a@redhat.com>
Date:   Thu May 15 12:42:49 2014 -0600

    PCI: shpchp: Check bridge's secondary (not primary) bus speed

    commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

    When a new device is added below a hotplug bridge, the bridge's secondary
    bus speed and the device's bus speed must match.  The shpchp driver
    previously checked the bridge's *primary* bus speed, not the secondary bus
    speed.

    This caused hot-add errors like:

      shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

    Check the secondary bus speed instead.

    [bhelgaas: changelog]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
    Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
    Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa5be5ba3f74b7b33568068aae4c33280cfec679
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 14 16:33:54 2014 -0700

    x86-64, modify_ldt: Make support for 16-bit segments a runtime option

    commit fa81511bb0bbb2b1aace3695ce869da9762624ff upstream.

    Checkin:

    b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

    disabled 16-bit segments on 64-bit kernels due to an information
    leak.  However, it does seem that people are genuinely using Wine to
    run old 16-bit Windows programs on Linux.

    A proper fix for this ("espfix64") is coming in the upcoming merge
    window, but as a temporary fix, create a sysctl to allow the
    administrator to re-enable support for 16-bit segments.

    It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
    you hit this issue and care about your old Windows program more than
    you care about a kernel stack address information leak, you can do

       echo 1 > /proc/sys/abi/ldt16

    as root (add it to your startup scripts), and you should be ok.

    The sysctl table is only added if you have COMPAT support enabled on
    x86-64, but I assume anybody who runs old windows binaries very much
    does that ;)

    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d2d976db078c71cd9c26dbed9b4c46534f703da
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Tue May 13 13:45:15 2014 +0100

    ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile

    commit 44330ab516c15dda8a1e660eeaf0003f84e43e3f upstream.

    The register CLASS_D_CONTROL_1 is marked as volatile because it contains
    a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1
    register. This causes problems for the "Speaker Switch" control, which
    will report an error if the CODEC is suspended because it relies on a
    volatile register.

    To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and
    manually keep the register cache in sync by updating both bits when
    changing the mute status.

    Reported-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Tested-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 063d8d3168bb3fb74810735bba88ef694062887b
Author: Jianyu Zhan <nasa4836@gmail.com>
Date:   Mon Apr 14 13:47:40 2014 +0800

    percpu: make pcpu_alloc_chunk() use pcpu_mem_free() instead of kfree()

    commit 5a838c3b60e3a36ade764cf7751b8f17d7c9c2da upstream.

    pcpu_chunk_struct_size = sizeof(struct pcpu_chunk) +
    	BITS_TO_LONGS(pcpu_unit_pages) * sizeof(unsigned long)

    It hardly could be ever bigger than PAGE_SIZE even for large-scale machine,
    but for consistency with its couterpart pcpu_mem_zalloc(),
    use pcpu_mem_free() instead.

    Commit b4916cb17c26 ("percpu: make pcpu_free_chunk() use
    pcpu_mem_free() instead of kfree()") addressed this problem, but
    missed this one.

    tj: commit message updated

    Signed-off-by: Jianyu Zhan <nasa4836@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: 099a19d91ca4 ("percpu: allow limited allocation before slab is online)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f521947cd3f688510ac1e8b28ac5daaf85cd3517
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue May 20 15:55:21 2014 -0400

    nfsd4: remove lockowner when removing lock stateid

    commit a1b8ff4c97b4375d21b6d6c45d75877303f61b3b upstream.

    The nfsv4 state code has always assumed a one-to-one correspondance
    between lock stateid's and lockowners even if it appears not to in some
    places.

    We may actually change that, but for now when FREE_STATEID releases a
    lock stateid it also needs to release the parent lockowner.

    Symptoms were a subsequent LOCK crashing in find_lockowner_str when it
    calls same_lockowner_ino on a lockowner that unexpectedly has an empty
    so_stateids list.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87f3427c422328668ccae0a61820cb8a78d4f5ae
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu May 8 11:19:41 2014 -0400

    nfsd4: warn on finding lockowner without stateid's

    commit 27b11428b7de097c42f205beabb1764f4365443b upstream.

    The current code assumes a one-to-one lockowner<->lock stateid
    correspondance.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23770824ab398da9a0cca0d444e95a64493f8a3f
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Fri Apr 18 20:49:04 2014 +0800

    NFSD: Call ->set_acl with a NULL ACL structure if no entries

    commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec upstream.

    After setting ACL for directory, I got two problems that caused
    by the cached zero-length default posix acl.

    This patch make sure nfsd4_set_nfs4_acl calls ->set_acl
    with a NULL ACL structure if there are no entries.

    Thanks for Christoph Hellwig's advice.

    First problem:
    ............ hang ...........

    Second problem:
    [ 1610.167668] ------------[ cut here ]------------
    [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239!
    [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
    [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE)
    rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack
    rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
    ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
    ip6table_mangle ip6table_security ip6table_raw ip6table_filter
    ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
    nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw
    auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus
    snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev
    i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi
    [last unloaded: nfsd]
    [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G           OE
    3.15.0-rc1+ #15
    [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
    VirtualBox 12/01/2006
    [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti:
    ffff88005a944000
    [ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>]  [<ffffffffa034d5ed>]
    _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd]
    [ 1610.168320] RSP: 0018:ffff88005a945b00  EFLAGS: 00010293
    [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX:
    0000000000000000
    [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI:
    ffff880068233300
    [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09:
    0000000000000000
    [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12:
    ffff880068233300
    [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15:
    ffff880068233300
    [ 1610.168320] FS:  0000000000000000(0000) GS:ffff880077800000(0000)
    knlGS:0000000000000000
    [ 1610.168320] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4:
    00000000000006f0
    [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [ 1610.168320] Stack:
    [ 1610.168320]  ffffffff00000000 0000000b67c83500 000000076700bac0
    0000000000000000
    [ 1610.168320]  ffff88006700bac0 ffff880068233300 ffff88005a945c08
    0000000000000002
    [ 1610.168320]  0000000000000000 ffff88005a945b88 ffffffffa034e2d5
    000000065a945b68
    [ 1610.168320] Call Trace:
    [ 1610.168320]  [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd]
    [ 1610.168320]  [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd]
    [ 1610.168320]  [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0
    [ 1610.168320]  [<ffffffffa0327962>] ?
    nfsd_setuser_and_check_port+0x52/0x80 [nfsd]
    [ 1610.168320]  [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30
    [ 1610.168320]  [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd]
    [ 1610.168320]  [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110
    [nfsd]
    [ 1610.168320]  [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd]
    [ 1610.168320]  [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd]
    [ 1610.168320]  [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc]
    [ 1610.168320]  [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc]
    [ 1610.168320]  [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd]
    [ 1610.168320]  [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [ 1610.168320]  [<ffffffff810a5202>] kthread+0xd2/0xf0
    [ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
    [ 1610.168320]  [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0
    [ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
    [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce
    41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd
    ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c
    [ 1610.168320] RIP  [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0
    [nfsd]
    [ 1610.168320]  RSP <ffff88005a945b00>
    [ 1610.257313] ---[ end trace 838254e3e352285b ]---

    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3ffc257a60da682d0a814d85314791419c420b5
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Tue Mar 4 10:09:39 2014 +0100

    trace: module: Maintain a valid user count

    commit 098507ae3ec2331476fb52e85d4040c1cc6d0ef4 upstream.

    The replacement of the 'count' variable by two variables 'incs' and
    'decs' to resolve some race conditions during module unloading was done
    in parallel with some cleanup in the trace subsystem, and was integrated
    as a merge.

    Unfortunately, the formula for this replacement was wrong in the tracing
    code, and the refcount in the traces was not usable as a result.

    Use 'count = incs - decs' to compute the user count.

    Link: http://lkml.kernel.org/p/1393924179-9147-1-git-send-email-romain.izard.pro@gmail.com

    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Fixes: c1ab9cab7509 "merge conflict resolution"
    Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c91081b35aa80754dee66d560f43a179ef70eac
Author: Salva Peiró <speiro@ai2.upv.es>
Date:   Wed Apr 30 19:48:02 2014 +0200

    media: media-device: fix infoleak in ioctl media_enum_entities()

    commit e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream.

    This fixes CVE-2014-1739.

    Signed-off-by: Salva Peiró <speiro@ai2.upv.es>
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1581a6de8e530adc4f4513faa554a1f59f365be
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Mon Mar 17 16:52:26 2014 -0700

    crypto: crypto_wq - Fix late crypto work queue initialization

    commit 130fa5bc81b44b6cc1fbdea3abf6db0da22964e0 upstream.

    The crypto algorithm modules utilizing the crypto daemon could
    be used early when the system start up.  Using module_init
    does not guarantee that the daemon's work queue is initialized
    when the cypto alorithm depending on crypto_wq starts.  It is necessary
    to initialize the crypto work queue earlier at the subsystem
    init time to make sure that it is initialized
    when used.

    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4634dcc2f783a47e4000017eb29c6ae5a857c876
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Apr 14 18:52:14 2014 +0200

    Documentation: Update stable address in Chinese and Japanese translations

    commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.

    The English and Korean translations were updated, the Chinese and Japanese
    weren't.

    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18f37d667edb688f5fd61b77472e30b0181083e5
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Mar 26 19:37:21 2014 -0400

    drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi

    commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream.

    There appear to be a crop of new hardware where the vbios is not
    available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
    The data read from PCIROM almost invariably contains invalid
    instructions (still has the x86 opcodes), which makes this a low-risk
    way to try to obtain a valid vbios image.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ea12b53b736c0b402e0c2f66260c5ea28e93402
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Apr 26 21:59:04 2014 +0100

    rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()

    commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.

    Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2604ca1871a4802984349cbb01ea1a695755dcda
Author: Liu Hua <sdu.liu@huawei.com>
Date:   Thu Mar 27 06:56:18 2014 +0100

    ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr

    commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream.

    When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
    overflow if pfn >= 0x100000 in copy_oldmem_page.
    So use __pfn_to_phys for converting.

    Signed-off-by: Liu Hua <sdu.liu@huawei.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5de3bdab49a5c0d5e90fec9ebebd35f4e98f8ea
Author: Christoph Hellwig <hch@lst.de>
Date:   Sun May 4 13:03:32 2014 +0200

    posix_acl: handle NULL ACL in posix_acl_equiv_mode

    commit 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 upstream.

    Various filesystems don't bother checking for a NULL ACL in
    posix_acl_equiv_mode, and thus can dereference a NULL pointer when it
    gets passed one. This usually happens from the NFS server, as the ACL tools
    never pass a NULL ACL, but instead of one representing the mode bits.

    Instead of adding boilerplat to all filesystems put this check into one place,
    which will allow us to remove the check from other filesystems as well later
    on.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Ben Greear <greearb@candelatech.com>
    Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>,
    Cc: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c451eb87f0f07a7597b294b1147d3c2392aaea2f
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Apr 17 11:08:47 2014 +0200

    rt2x00: fix beaconing on USB

    commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.

    When disable beaconing we clear register with beacon and newer set it
    back, what make we stop send beacons infinitely.

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

commit 92983a1d23dd8945ad131275d23ea3820fc8f44a
Author: Daniele Forsi <dforsi@gmail.com>
Date:   Mon Apr 28 17:09:11 2014 +0200

    USB: Nokia 5300 should be treated as unusual dev

    commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream.

    Signed-off-by: Daniele Forsi <dforsi@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c4cbd6508dad9d29be7e2ea7fd6be7c8792d69d
Author: Victor A. Santos <victoraur.santos@gmail.com>
Date:   Sat Apr 26 23:20:14 2014 -0300

    USB: Nokia 305 should be treated as unusual dev

    commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream.

    Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6396b5285764d0b4a6246a280ad26864990fb940
Author: Daniele Forsi <dforsi@gmail.com>
Date:   Tue Apr 29 11:44:03 2014 +0200

    usb: storage: shuttle_usbat: fix discs being detected twice

    commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream.

    Even if the USB-to-ATAPI converter supported multiple LUNs, this
    driver would always detect the same physical device or media because
    it doesn't use srb->device->lun in any way.
    Tested with an Hewlett-Packard CD-Writer Plus 8200e.

    Signed-off-by: Daniele Forsi <dforsi@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04000cff935e053f89c62d1a4ddd907b1281630c
Author: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Date:   Wed Mar 12 17:30:08 2014 +0100

    usb: gadget: at91-udc: fix irq and iomem resource retrieval

    commit 886c7c426d465732ec9d1b2bbdda5642fc2e7e05 upstream.

    When using dt resources retrieval (interrupts and reg properties) there is
    no predefined order for these resources in the platform dev resource
    table. Also don't expect the number of resource to be always 2.

    Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
    Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48f05c73d99078db9bd2c073b625736a39726229
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Tue Apr 15 12:44:34 2014 -0400

    drm/radeon: fix ATPX detection on non-VGA GPUs

    commit e9a4099a59cc598a44006059dd775c25e422b772 upstream.

    Some newer PX laptops have the pci device class
    set to DISPLAY_OTHER rather than DISPLAY_VGA.  This
    properly detects ATPX on those laptops.

    Based on a patch from: Pali Rohár <pali.rohar@gmail.com>

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35a779520b52e5d30348c47c8a07ea6aa57c7f3f
Author: NeilBrown <neilb@suse.de>
Date:   Tue May 6 09:36:08 2014 +1000

    md: avoid possible spinning md thread at shutdown.

    commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.

    If an md array with externally managed metadata (e.g. DDF or IMSM)
    is in use, then we should not set safemode==2 at shutdown because:

    1/ this is ineffective: user-space need to be involved in any 'safemode' handling,
    2/ The safemode management code doesn't cope with safemode==2 on external metadata
       and md_check_recover enters an infinite loop.

    Even at shutdown, an infinite-looping process can be problematic, so this
    could cause shutdown to hang.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67d44b5aac11103c3588d59071abdc801d3c470b
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Mon May 12 13:42:29 2014 +0530

    hrtimer: Set expiry time before switch_hrtimer_base()

    commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.

    switch_hrtimer_base() calls hrtimer_check_target() which ensures that
    we do not migrate a timer to a remote cpu if the timer expires before
    the current programmed expiry time on that remote cpu.

    But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
    new expiry time is set. So the sanity check in hrtimer_check_target()
    is operating on stale or even uninitialized data.

    Update expiry time before calling switch_hrtimer_base().

    [ tglx: Rewrote changelog once again ]

    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: linaro-kernel@lists.linaro.org
    Cc: linaro-networking@linaro.org
    Cc: fweisbec@gmail.com
    Cc: arvind.chauhan@arm.com
    Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53674d9d1b27c642ab4acfe4003c414038c83246
Author: Leon Ma <xindong.ma@intel.com>
Date:   Wed Apr 30 16:43:10 2014 +0800

    hrtimer: Prevent remote enqueue of leftmost timers

    commit 012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream.

    If a cpu is idle and starts an hrtimer which is not pinned on that
    same cpu, the nohz code might target the timer to a different cpu.

    In the case that we switch the cpu base of the timer we already have a
    sanity check in place, which determines whether the timer is earlier
    than the current leftmost timer on the target cpu. In that case we
    enqueue the timer on the current cpu because we cannot reprogram the
    clock event device on the target.

    If the timers base is already the target CPU we do not have this
    sanity check in place so we enqueue the timer as the leftmost timer in
    the target cpus rb tree, but we cannot reprogram the clock event
    device on the target cpu. So the timer expires late and subsequently
    prevents the reprogramming of the target cpu clock event device until
    the previously programmed event fires or a timer with an earlier
    expiry time gets enqueued on the target cpu itself.

    Add the same target check as we have for the switch base case and
    start the timer on the current cpu if it would become the leftmost
    timer on the target.

    [ tglx: Rewrote subject and changelog ]

    Signed-off-by: Leon Ma <xindong.ma@intel.com>
    Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c3c9e9d02466113d25ffc1a3e4cd599810cd54
Author: Stuart Hayes <stuart.w.hayes@gmail.com>
Date:   Tue Apr 29 17:55:02 2014 -0500

    hrtimer: Prevent all reprogramming if hang detected

    commit 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream.

    If the last hrtimer interrupt detected a hang it sets hang_detected=1
    and programs the clock event device with a delay to let the system
    make progress.

    If hang_detected == 1, we prevent reprogramming of the clock event
    device in hrtimer_reprogram() but not in hrtimer_force_reprogram().

    This can lead to the following situation:

    hrtimer_interrupt()
       hang_detected = 1;
       program ce device to Xms from now (hang delay)

    We have two timers pending:
       T1 expires 50ms from now
       T2 expires 5s from now

    Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
    invoked, which in turn programs the clock event device to T2 (5
    seconds from now).

    Any hrtimer_start after that will not reprogram the hardware due to
    hang_detected still being set. So we effectivly block all timers until
    the T2 event fires and cleans up the hang situation.

    Add a check for hang_detected to hrtimer_force_reprogram() which
    prevents the reprogramming of the hang delay in the hardware
    timer. The subsequent hrtimer_interrupt will resolve all outstanding
    issues.

    [ tglx: Rewrote subject and changelog and fixed up the comment in
      	hrtimer_force_reprogram() ]

    Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
    Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96b9cef886bfbb5dcb96b0a1b4f28776a49e267e
Author: Grant Likely <grant.likely@linaro.org>
Date:   Tue Apr 29 12:05:22 2014 +0100

    drivercore: deferral race condition fix

    commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.

    When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
    when all modules loaded but some driver still stuck in the deferred list
    and there is a need for external event to kick the deferred queue to probe
    these drivers.

    The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
    audio support built as modules and using nfsroot for root filesystem.

    The following log fragment shows such sequence when all audio modules
    were loaded but the sound card is not present since the machine driver has
    failed to probe due to missing dependency during it's probe.
    The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
    machine driver:

    ...
    [   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
    [   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
    [   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
    [   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
    [   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
    [   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
    [   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
    [   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
    [   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
    [   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
    [   13.346755] davinci_mcasp_driver_init: LEAVE
    [   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
    [   13.592527] platform sound.3: really_probe: probe_count = 0

    In the log the machine driver enters it's probe at 12.719969 (this point it
    has been removed from the deferred lists). McASP driver already executing
    it's probing (since 12.615118).
    The machine driver tries to construct the sound card (12.950839) but did
    not found one of the components so it fails. After this McASP driver
    registers all the ASoC components (the machine driver still in it's probe
    function after it failed to construct the card) and the deferred work is
    prepared at 13.099026 (note that this time the machine driver is not in the
    lists so it is not going to be handled when the work is executing).
    Lastly the machine driver exit from it's probe and the core places it to
    the deferred list but there will be no other driver going to load and the
    deferred queue is not going to be kicked again - till we have external event
    like connecting USB stick, etc.

    The proposed solution is to try the deferred queue once more when the last
    driver is asking for deferring and we had drivers loaded while this last
    driver was probing.

    This way we can avoid drivers stuck in the deferred queue.

    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d2555ccbdb13b0f17f68c2876186fa5d10c1a13
Author: Josef Gajdusek <atx@atx.name>
Date:   Mon May 12 13:48:26 2014 +0200

    hwmon: (emc1403) Support full range of known chip revision numbers

    commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream.

    The datasheet for EMC1413/EMC1414, which is fully compatible to
    EMC1403/1404 and uses the same chip identification, references revision
    numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers
    from 0x01 to 0x04 to make sure none are missed.

    Signed-off-by: Josef Gajdusek <atx@atx.name>
    [Guenter Roeck: Updated headline and description]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93264243d2839d474d4f064e4099792003a6ca6f
Author: Josef Gajdusek <atx@atx.name>
Date:   Sun May 11 14:40:44 2014 +0200

    hwmon: (emc1403) fix inverted store_hyst()

    commit 17c048fc4bd95efea208a1920f169547d8588f1f upstream.

    Attempts to set the hysteresis value to a temperature below the target
    limit fails with "write error: Numerical result out of range" due to
    an inverted comparison.

    Signed-off-by: Josef Gajdusek <atx@atx.name>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    [Guenter Roeck: Updated headline and description]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b7379a7168835819a273cb15bb8b2cff00c9f7c
Author: Chen Yucong <slaoub@gmail.com>
Date:   Thu May 22 11:54:15 2014 -0700

    hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage

    commit b985194c8c0a130ed155b71662e39f7eaea4876f upstream.

    For handling a free hugepage in memory failure, the race will happen if
    another thread hwpoisoned this hugepage concurrently.  So we need to
    check PageHWPoison instead of !PageHWPoison.

    If hwpoison_filter(p) returns true or a race happens, then we need to
    unlock_page(hpage).

    Signed-off-by: Chen Yucong <slaoub@gmail.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c712a1ce78757bc250af3b100bfc525f4a7541f
Author: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
Date:   Wed May 14 11:29:48 2014 +0200

    x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()

    commit 9844f5462392b53824e8b86726e7c33b5ecbb676 upstream.

    The invalidation is required in order to maintain proper semantics
    under CoW conditions. In scenarios where a process clones several
    threads, a thread operating on a core whose DTLB entry for a
    particular hugepage has not been invalidated, will be reading from
    the hugepage that belongs to the forked child process, even after
    hugetlb_cow().

    The thread will not see the updated page as long as the stale DTLB
    entry remains cached, the thread attempts to write into the page,
    the child process exits, or the thread gets migrated to a different
    processor.

    Signed-off-by: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
    Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corp
    Suggested-by: Shay Goikhman <shay.goikhman@huawei.com>
    Acked-by: Dave Hansen <dave.hansen@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f7a4c19a1e171491e03e4c8b92a54da0bab05e4
Author: Corey Minyard <cminyard@mvista.com>
Date:   Mon Apr 14 09:46:52 2014 -0500

    ipmi: Reset the KCS timeout when starting error recovery

    commit eb6d78ec213e6938559b801421d64714dafcf4b2 upstream.

    The OBF timer in KCS was not reset in one situation when error recovery
    was started, resulting in an immediate timeout.

    Reported-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 832301075af0bbd50af3f2f19417ef92599a04dd
Author: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Date:   Mon Apr 14 09:46:51 2014 -0500

    ipmi: Fix a race restarting the timer

    commit 48e8ac2979920ffa39117e2d725afa3a749bfe8d upstream.

    With recent changes it is possible for the timer handler to detect an
    idle interface and not start the timer, but the thread to start an
    operation at the same time.  The thread will not start the timer in that
    instance, resulting in the timer not running.

    Instead, move all timer operations under the lock and start the timer in
    the thread if it detect non-idle and the timer is not already running.
    Moving under locks allows the last timeout to be set in both the thread
    and the timer.  'Timer is not running' means that the timer is not
    pending and smi_timeout() is not running.  So we need a flag to detect
    this correctly.

    Also fix a few other timeout bugs: setting the last timeout when the
    interrupt has to be disabled and the timer started, and setting the last
    timeout in check_start_timer_thread possibly racing with the timer

    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd5294bacb897a879267b535f0741da720034b83
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Apr 18 17:23:11 2014 +0200

    timer: Prevent overflow in apply_slack

    commit 98a01e779f3c66b0b11cd7e64d531c0e41c95762 upstream.

    On architectures with sizeof(int) < sizeof (long), the
    computation of mask inside apply_slack() can be undefined if the
    computed bit is > 32.

    E.g. with: expires = 0xffffe6f5 and slack = 25, we get:

    expires_limit = 0x20000000e
    bit = 33
    mask = (1 << 33) - 1  /* undefined */

    On x86, mask becomes 1 and and the slack is not applied properly.
    On s390, mask is -1, expires is set to 0 and the timer fires immediately.

    Use 1UL << bit to solve that issue.

    Suggested-by: Deborah Townsend <dstownse@us.ibm.com>
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1d0e51763b4708110812c08a2da84ea60adb34
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Apr 22 13:49:40 2014 -0700

    mm: make fixup_user_fault() check the vma access rights too

    commit 1b17844b29ae042576bea588164f2f1e9590a8bc upstream.

    fixup_user_fault() is used by the futex code when the direct user access
    fails, and the futex code wants it to either map in the page in a usable
    form or return an error.  It relied on handle_mm_fault() to map the
    page, and correctly checked the error return from that, but while that
    does map the page, it doesn't actually guarantee that the page will be
    mapped with sufficient permissions to be then accessed.

    So do the appropriate tests of the vma access rights by hand.

    [ Side note: arguably handle_mm_fault() could just do that itself, but
      we have traditionally done it in the caller, because some callers -
      notably get_user_pages() - have been able to access pages even when
      they are mapped with PROT_NONE.  Maybe we should re-visit that design
      decision, but in the meantime this is the minimal patch. ]

    Found by Dave Jones running his trinity tool.

    Reported-by: Dave Jones <davej@redhat.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffd6979b69a24203fe289ec9d3656a1745037e3f
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Mon Mar 31 19:51:14 2014 +0200

    pata_at91: fix ata_host_activate() failure handling

    commit 27aa64b9d1bd0d23fd692c91763a48309b694311 upstream.

    Add missing clk_put() call to ata_host_activate() failure path.

    Sergei says,

      "Hm, I have once fixed that (see that *if* (!ret)) but looks like a
       later commit 477c87e90853d136b188c50c0e4a93d01cad872e (ARM:
       at91/pata: use gpio_is_valid to check the gpio) broke it again. :-(
       Would be good if the changelog did mention that..."

    Cc: Andrew Victor <linux@maxim.org.za>
    Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
    Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90ada3f5e5573174df014f7ce32137cded70511f
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Apr 24 10:40:12 2014 -0400

    ftrace/module: Hardcode ftrace_module_init() call into load_module()

    commit a949ae560a511fe4e3adf48fa44fefded93e5c2b upstream.

    A race exists between module loading and enabling of function tracer.

    	CPU 1				CPU 2
    	-----				-----
      load_module()
       module->state = MODULE_STATE_COMING

    				register_ftrace_function()
    				 mutex_lock(&ftrace_lock);
    				 ftrace_startup()
    				  update_ftrace_function();
    				   ftrace_arch_code_modify_prepare()
    				    set_all_module_text_rw();
    				   <enables-ftrace>
    				    ftrace_arch_code_modify_post_process()
    				     set_all_module_text_ro();

    				[ here all module text is set to RO,
    				  including the module that is
    				  loading!! ]

       blocking_notifier_call_chain(MODULE_STATE_COMING);
        ftrace_init_module()

         [ tries to modify code, but it's RO, and fails!
           ftrace_bug() is called]

    When this race happens, ftrace_bug() will produces a nasty warning and
    all of the function tracing features will be disabled until reboot.

    The simple solution is to treate module load the same way the core
    kernel is treated at boot. To hardcode the ftrace function modification
    of converting calls to mcount into nops. This is done in init/main.c
    there's no reason it could not be done in load_module(). This gives
    a better control of the changes and doesn't tie the state of the
    module to its notifiers as much. Ftrace is special, it needs to be
    treated as such.

    The reason this would work, is that the ftrace_module_init() would be
    called while the module is in MODULE_STATE_UNFORMED, which is ignored
    by the set_all_module_text_ro() call.

    Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com

    Reported-by: Takao Indoh <indou.takao@jp.fujitsu.com>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a398e500c1eead44cba62c0c5bc913eecefeefa
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 12 20:45:35 2014 +0000

    futex: Prevent attaching to kernel threads

    commit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream.

    We happily allow userspace to declare a random kernel thread to be the
    owner of a user space PI futex.

    Found while analysing the fallout of Dave Jones syscall fuzzer.

    We also should validate the thread group for private futexes and find
    some fast way to validate whether the "alleged" owner has RW access on
    the file which backs the SHM, but that's a separate issue.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Darren Hart <darren@dvhart.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Cc: Roland McGrath <roland@hack.frob.com>
    Cc: Carlos ODonell <carlos@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3c24925f63119ed2ec9181d43ed32a0a4ac55a7
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 12 20:45:34 2014 +0000

    futex: Add another early deadlock detection check

    commit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream.

    Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
    detection code of rtmutex:
      http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

    That underlying issue has been fixed with a patch to the rtmutex code,
    but the futex code must not call into rtmutex in that case because
        - it can detect that issue early
        - it avoids a different and more complex fixup for backing out

    If the user space variable got manipulated to 0x80000000 which means
    no lock holder, but the waiters bit set and an active pi_state in the
    kernel is found we can figure out the recursive locking issue by
    looking at the pi_state owner. If that is the current task, then we
    can safely return -EDEADLK.

    The check should have been added in commit 59fa62451 (futex: Handle
    futex_pi OWNER_DIED take over correctly) already, but I did not see
    the above issue caused by user space manipulation back then.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Darren Hart <darren@dvhart.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Cc: Roland McGrath <roland@hack.frob.com>
    Cc: Carlos ODonell <carlos@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    net-gro: reset skb->truesize in napi_reuse_skb()

    [ Upstream commit e33d0ba8047b049c9262fdb1fcafb93cb52ceceb ]

    Recycling skb always had been very tough...

    This time it appears GRO layer can accumulate skb->truesize
    adjustments made by drivers when they attach a fragment to skb.

    skb_gro_receive() can only subtract from skb->truesize the used part
    of a fragment.

    I spotted this problem seeing TcpExtPruneCalled and
    TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where
    TCP receive window should be sized properly to accept traffic coming
    from a driver not overshooting skb->truesize.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cc64da2c1ed37bbd24cdcdb30bf8192473972d0
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date:   Fri May 4 14:26:56 2012 +0000

    skb: Add inline helper for getting the skb end offset from head

    [ Upstream commit ec47ea82477404631d49b8e568c71826c9b663ac ]

    With the recent changes for how we compute the skb truesize it occurs to me
    we are probably going to have a lot of calls to skb_end_pointer -
    skb->head.  Instead of running all over the place doing that it would make
    more sense to just make it a separate inline skb_end_offset(skb) that way
    we can return the correct value without having gcc having to do all the
    optimization to cancel out skb->head - skb->head.

    Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ipv4: initialise the itag variable in __mkroute_input

    [ Upstream commit fbdc0ad095c0a299e9abf5d8ac8f58374951149a ]

    the value of itag is a random value from stack, and may not be initiated by
    fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID
    is not set

    This will make the cached dst uncertainty

    Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
    Acked-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcf4649dfa916e62d25a4a6bdd0562f1428c3560
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Aug 15 20:44:27 2012 +0000

    act_mirred: do not drop packets when fails to mirror it

    [ Upstream commit 16c0b164bd24d44db137693a36b428ba28970c62 ]

    We drop packet unconditionally when we fail to mirror it. This is not intended
    in some cases. Consdier for kvm guest, we may mirror the traffic of the bridge
    to a tap device used by a VM. When kernel fails to mirror the packet in
    conditions such as when qemu crashes or stop polling the tap, it's hard for the
    management software to detect such condition and clean the the mirroring
    before. This would lead all packets to the bridge to be dropped and break the
    netowrk of other virtual machines.

    To solve the issue, the patch does not drop packets when kernel fails to mirror
    it, and only drop the redirected packets.

    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ipv4: fib_semantics: increment fib_info_cnt after fib_info allocation

    [ Upstream commit aeefa1ecfc799b0ea2c4979617f14cecd5cccbfd ]

    Increment fib_info_cnt in fib_create_info() right after successfuly
    alllocating fib_info structure, overwise fib_metrics allocation failure
    leads to fib_info_cnt incorrectly decremented in free_fib_info(), called
    on error path from fib_create_info().

    Signed-off-by: Sergey Popovich <popovich_sergei@mail.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    net: ipv4: ip_forward: fix inverted local_df test

    [ Upstream commit ca6c5d4ad216d5942ae544bbf02503041bd802aa ]

    local_df means 'ignore DF bit if set', so if its set we're
    allowed to perform ip fragmentation.

    This wasn't noticed earlier because the output path also drops such skbs
    (and emits needed icmp error) and because netfilter ip defrag did not
    set local_df until couple of days ago.

    Only difference is that DF-packets-larger-than MTU now discarded
    earlier (f.e. we avoid pointless netfilter postrouting trip).

    While at it, drop the repeated test ip_exceeds_mtu, checking it once
    is enough...

    Fixes: fe6cc55f3a9 ("net: ip, ipv6: handle gso skbs in forwarding path")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tcp_cubic: fix the range of delayed_ack

    [ Upstream commit 0cda345d1b2201dd15591b163e3c92bad5191745 ]

    commit b9f47a3aaeab (tcp_cubic: limit delayed_ack ratio to prevent
    divide error) try to prevent divide error, but there is still a little
    chance that delayed_ack can reach zero. In case the param cnt get
    negative value, then ratio+cnt would overflow and may happen to be zero.
    As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero.

    In some old kernels, such as 2.6.32, there is a bug that would
    pass negative param, which then ultimately leads to this divide error.

    commit 5b35e1e6e9c (tcp: fix tcp_trim_head() to adjust segment count
    with skb MSS) fixed the negative param issue. However,
    it's safe that we fix the range of delayed_ack as well,
    to make sure we do not hit a divide by zero.

    CC: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: Liu Yu <allanyuliu@tencent.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    Revert "macvlan : fix checksums error when we are in bridge mode"

    [ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ]

    This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019.
    The commit above doesn't appear to be necessary any more as the
    checksums appear to be correctly computed/validated.

    Additionally the above commit breaks kvm configurations where
    one VM is using a device that support checksum offload (virtio) and
    the other VM does not.
    In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
    set.  The packets is forwarded to a macvtap that has offload features
    turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
    update the checksum and thus a bad checksum is passed up to
    the guest.

    CC: Daniel Lezcano <daniel.lezcano@free.fr>
    CC: Patrick McHardy <kaber@trash.net>
    CC: Andrian Nord <nightnord@gmail.com>
    CC: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Michael S. Tsirkin <mst@redhat.com>
    CC: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set

    [ Upstream commit c53864fd60227de025cb79e05493b13f69843971 ]

    Since 115c9b81928360d769a76c632bae62d15206a94a (rtnetlink: Fix problem with
    buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST
    attribute if they were solicited by a GETLINK message containing an
    IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag.

    That was done because some user programs broke when they received more data
    than expected - because IFLA_VFINFO_LIST contains information for each VF
    it can become large if there are many VFs.

    However, the IFLA_VF_PORTS attribute, supplied for devices which implement
    ndo_get_vf_port (currently the 'enic' driver only), has the same problem.
    It supplies per-VF information and can therefore become large, but it is
    not currently conditional on the IFLA_EXT_MASK value.

    Worse, it interacts badly with the existing EXT_MASK handling.  When
    IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at
    NLMSG_GOODSIZE.  If the information for IFLA_VF_PORTS exceeds this, then
    rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet.
    netlink_dump() will misinterpret this as having finished the listing and
    omit data for this interface and all subsequent ones.  That can cause
    getifaddrs(3) to enter an infinite loop.

    This patch addresses the problem by only supplying IFLA_VF_PORTS when
    IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set.

    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    rtnetlink: Warn when interface's information won't fit in our packet

    [ Upstream commit 973462bbde79bb827824c73b59027a0aed5c9ca6 ]

    Without IFLA_EXT_MASK specified, the information reported for a single
    interface in response to RTM_GETLINK is expected to fit within a netlink
    packet of NLMSG_GOODSIZE.

    If it doesn't, however, things will go badly wrong,  When listing all
    interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first
    message in a packet as the end of the listing and omit information for
    that interface and all subsequent ones.  This can cause getifaddrs(3) to
    enter an infinite loop.

    This patch won't fix the problem, but it will WARN_ON() making it easier to
    track down what's going wrong.

    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled

    The patch fixes a problem with dropped jumbo frames after usage of
    'ethtool -G ... rx'.

    Scenario:
    1. ip link set eth0 up
    2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo
    3. ip link set mtu 9000 dev eth0

    The ethtool command set rx_jumbo_pending to zero so any received jumbo
    packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N'
    to workaround the issue.
    The patch changes the logic so rx_jumbo_pending value is changed only if
    jumbo frames are enabled (MTU > 1500).

    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Acked-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    filter: prevent nla extensions to peek beyond the end of the message

    [ Upstream commit 05ab8f2647e4221cbdb3856dd7d32bd5407316b3 ]

    The BPF_S_ANC_NLATTR and BPF_S_ANC_NLATTR_NEST extensions fail to check
    for a minimal message length before testing the supplied offset to be
    within the bounds of the message. This allows the subtraction of the nla
    header to underflow and therefore -- as the data type is unsigned --
    allowing far to big offset and length values for the search of the
    netlink attribute.

    The remainder calculation for the BPF_S_ANC_NLATTR_NEST extension is
    also wrong. It has the minuend and subtrahend mixed up, therefore
    calculates a huge length value, allowing to overrun the end of the
    message while looking for the netlink attribute.

    The following three BPF snippets will trigger the bugs when attached to
    a UNIX datagram socket and parsing a message with length 1, 2 or 3.

     ,-[ PoC for missing size check in BPF_S_ANC_NLATTR ]--
     | ld	#0x87654321
     | ldx	#42
     | ld	#nla
     | ret	a
     `---

     ,-[ PoC for the same bug in BPF_S_ANC_NLATTR_NEST ]--
     | ld	#0x87654321
     | ldx	#42
     | ld	#nlan
     | ret	a
     `---

     ,-[ PoC for wrong remainder calculation in BPF_S_ANC_NLATTR_NEST ]--
     | ; (needs a fake netlink header at offset 0)
     | ld	#0
     | ldx	#42
     | ld	#nlan
     | ret	a
     `---

    Fix the first issue by ensuring the message length fulfills the minimal
    size constrains of a nla header. Fix the second bug by getting the math
    for the remainder calculation right.

    Fixes: 4738c1db15 ("[SKFILTER]: Add SKF_ADF_NLATTR instruction")
    Fixes: d214c7537b ("filter: add SKF_AD_NLATTR_NEST to look for nested..")
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Acked-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffd6e64af7d87e20c6a62fcd57d7f43c6cfd1530
Author: Wang, Xiaoming <xiaoming.wang@intel.com>
Date:   Mon Apr 14 12:30:45 2014 -0400

    net: ipv4: current group_info should be put after using.

    [ Upstream commit b04c46190219a4f845e46a459e3102137b7f6cac ]

    Plug a group_info refcount leak in ping_init.
    group_info is only needed during initialization and
    the code failed to release the reference on exit.
    While here move grabbing the reference to a place
    where it is actually needed.

    Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Signed-off-by: Zhang Dongxing <dongxing.zhang@intel.com>
    Signed-off-by: xiaoming wang <xiaoming.wang@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ipv6: Limit mtu to 65575 bytes

    [ Upstream commit 30f78d8ebf7f514801e71b88a10c948275168518 ]

    Francois reported that setting big mtu on loopback device could prevent
    tcp sessions making progress.

    We do not support (yet ?) IPv6 Jumbograms and cook corrupted packets.

    We must limit the IPv6 MTU to (65535 + 40) bytes in theory.

    Tested:

    ifconfig lo mtu 70000
    netperf -H ::1

    Before patch : Throughput :   0.05 Mbits

    After patch : Throughput : 35484 Mbits

    Reported-by: Francois WELLENREITER <f.wellenreiter@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    bonding: Remove debug_fs files when module init fails

    [ Upstream commit db29868653394937037d71dc3545768302dda643 ]

    Remove the bonding debug_fs entries when the
    module initialization fails. The debug_fs
    entries should be removed together with all other
    already allocated resources.

    Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Signed-off-by: Jay Vosburgh <j.vosburgh@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    net: core: don't account for udp header size when computing seglen

    [ Upstream commit 6d39d589bb76ee8a1c6cde6822006ae0053decff ]

    In case of tcp, gso_size contains the tcpmss.

    For UFO (udp fragmentation offloading) skbs, gso_size is the fragment
    payload size, i.e. we must not account for udp header size.

    Otherwise, when using virtio drivers, a to-be-forwarded UFO GSO packet
    will be needlessly fragmented in the forward path, because we think its
    individual segments are too large for the outgoing link.

    Fixes: fe6cc55f3a9a053 ("net: ip, ipv6: handle gso skbs in forwarding path")
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Reported-by: Tobias Brunner <tobias@strongswan.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    l2tp: take PMTU from tunnel UDP socket

    [ Upstream commit f34c4a35d87949fbb0e0f31eba3c054e9f8199ba ]

    When l2tp driver tries to get PMTU for the tunnel destination, it uses
    the pointer to struct sock that represents PPPoX socket, while it
    should use the pointer that represents UDP socket of the tunnel.

    Signed-off-by: Dmitry Petukhov <dmgenp@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    net: sctp: test if association is dead in sctp_wake_up_waiters

    [ Upstream commit 1e1cdf8ac78793e0875465e98a648df64694a8d0 ]

    In function sctp_wake_up_waiters(), we need to involve a test
    if the association is declared dead. If so, we don't have any
    reference to a possible sibling association anymore and need
    to invoke sctp_write_space() instead, and normally walk the
    socket's associations and notify them of new wmem space. The
    reason for special casing is that otherwise, we could run
    into the following issue when a sctp_primitive_SEND() call
    from sctp_sendmsg() fails, and tries to flush an association's
    outq, i.e. in the following way:

    sctp_association_free()
    `-> list_del(&asoc->asocs)         <-- poisons list pointer
        asoc->base.dead = true
        sctp_outq_free(&asoc->outqueue)
        `-> __sctp_outq_teardown()
         `-> sctp_chunk_free()
          `-> consume_skb()
           `-> sctp_wfree()
            `-> sctp_wake_up_waiters() <-- dereferences poisoned pointers
                                           if asoc->ep->sndbuf_policy=0

    Therefore, only walk the list in an 'optimized' way if we find
    that the current association is still active. We could also use
    list_del_init() in addition when we call sctp_association_free(),
    but as Vlad suggests, we want to trap such bugs and thus leave
    it poisoned as is.

    Why is it safe to resolve the issue by testing for asoc->base.dead?
    Parallel calls to sctp_sendmsg() are protected under socket lock,
    that is lock_sock()/release_sock(). Only within that path under
    lock held, we're setting skb/chunk owner via sctp_set_owner_w().
    Eventually, chunks are freed directly by an association still
    under that lock. So when traversing association list on destruction
    time from sctp_wake_up_waiters() via sctp_wfree(), a different
    CPU can't be running sctp_wfree() while another one calls
    sctp_association_free() as both happens under the same lock.
    Therefore, this can also not race with setting/testing against
    asoc->base.dead as we are guaranteed for this to happen in order,
    under lock. Further, Vlad says: the times we check asoc->base.dead
    is when we've cached an association pointer for later processing.
    In between cache and processing, the association may have been
    freed and is simply still around due to reference counts. We check
    asoc->base.dead under a lock, so it should always be safe to check
    and not race against sctp_association_free(). Stress-testing seems
    fine now, too.

    Fixes: cd253f9f357d ("net: sctp: wake up all assocs if sndbuf policy is per socket")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    net: sctp: wake up all assocs if sndbuf policy is per socket

    [ Upstream commit 52c35befb69b005c3fc5afdaae3a5717ad013411 ]

    SCTP charges chunks for wmem accounting via skb->truesize in
    sctp_set_owner_w(), and sctp_wfree() respectively as the
    reverse operation. If a sender runs out of wmem, it needs to
    wait via sctp_wait_for_sndbuf(), and gets woken up by a call
    to __sctp_write_space() mostly via sctp_wfree().

    __sctp_write_space() is being called per association. Although
    we assign sk->sk_write_space() to sctp_write_space(), which
    is then being done per socket, it is only used if send space
    is increased per socket option (SO_SNDBUF), as SOCK_USE_WRITE_QUEUE
    is set and therefore not invoked in sock_wfree().

    Commit 4c3a5bdae293 ("sctp: Don't charge for data in sndbuf
    again when transmitting packet") fixed an issue where in case
    sctp_packet_transmit() manages to queue up more than sndbuf
    bytes, sctp_wait_for_sndbuf() will never be woken up again
    unless it is interrupted by a signal. However, a still
    remaining issue is that if net.sctp.sndbuf_policy=0, that is
    accounting per socket, and one-to-many sockets are in use,
    the reclaimed write space from sctp_wfree() is 'unfairly'
    handed back on the server to the association that is the lucky
    one to be woken up again via __sctp_write_space(), while
    the remaining associations are never be woken up again
    (unless by a signal).

    The effect disappears with net.sctp.sndbuf_policy=1, that
    is wmem accounting per association, as it guarantees a fair
    share of wmem among associations.

    Therefore, if we have reclaimed memory in case of per socket
    accounting, wake all related associations to a socket in a
    fair manner, that is, traverse the socket association list
    starting from the current neighbour of the association and
    issue a __sctp_write_space() to everyone until we end up
    waking ourselves. This guarantees that no association is
    preferred over another and even if more associations are
    taken into the one-to-many session, all receivers will get
    messages from the server and are not stalled forever on
    high load. This setting still leaves the advantage of per
    socket accounting in touch as an association can still use
    up global limits if unused by others.

    Fixes: 4eb701dfc618 ("[SCTP] Fix SCTP sendbuffer accouting.")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Thomas Graf <tgraf@suug.ch>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    list: introduce list_next_entry() and list_prev_entry()

    [ Upstream commit 008208c6b26f21c2648c250a09c55e737c02c5f8 ]

    Add two trivial helpers list_next_entry() and list_prev_entry(), they
    can have a lot of users including list.h itself.  In fact the 1st one is
    already defined in events/core.c and bnx2x_sp.c, so the patch simply
    moves the definition to list.h.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Eilon Greenstein <eilong@broadcom.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm/radeon: call drm_edid_to_eld when we update the edid

    commit 16086279353cbfecbb3ead474072dced17b97ddc upstream.

    This needs to be done to update some of the fields in
    the connector structure used by the audio code.

    Noticed by several users on irc.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm/vmwgfx: correct fb_fix_screeninfo.line_length

    commit aa6de142c901cd2d90ef08db30ae87da214bedcc upstream.

    Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust
    the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour.

    See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.

    Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: option: add and update a number of CMOTech devices

    commit 34f972d6156fe9eea2ab7bb418c71f9d1d5c8e7b upstream.

    A number of older CMOTech modems are based on Qualcomm
    chips.  The blacklisted interfaces are QMI/wwan.

    Reported-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: option: add Alcatel L800MA

    commit dd6b48ecec2ea7d15f28d5e5474388681899a5e1 upstream.

    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/00/00 - serial AT+PPP
    2: ff/ff/ff - QMI/wwan
    3: 08/06/50 - storage

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: option: add Olivetti Olicard 500

    commit 533b3994610f316e5cd61b56d0c4daa15c830f89 upstream.

    Device interface layout:
    0: ff/ff/ff - serial
    1: ff/ff/ff - serial AT+PPP
    2: 08/06/50 - storage
    3: ff/ff/ff - serial
    4: ff/ff/ff - QMI/wwan

    Reported-by: Julio Araujo <julio.araujo@wllctel.com.br>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: io_ti: fix firmware download on big-endian machines

    commit 5509076d1b4485ce9fb07705fcbcd2695907ab5b upstream.

    During firmware download the device expects memory addresses in
    big-endian byte order. As the wIndex parameter which hold the address is
    sent in little-endian byte order regardless of host byte order, we need
    to use swab16 rather than cpu_to_be16.

    Also make sure to handle the struct ti_i2c_desc size parameter which is
    returned in little-endian byte order.

    Reported-by: Ludovic Drolez <ldrolez@debian.org>
    Tested-by: Ludovic Drolez <ldrolez@debian.org>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    Revert "USB: serial: add usbid for dell wwan card to sierra.c"

    commit 2e01280d2801c72878cf3a7119eac30077b463d5 upstream.

    This reverts commit 1ebca9dad5abe8b2ed4dbd186cd657fb47c1f321.

    This device was erroneously added to the sierra driver even though it's
    not a Sierra device and was already handled by the option driver.

    Cc: Richard Farina <sidhayn@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: option driver, add support for Telit UE910v2

    commit d6de486bc22255779bd54b0fceb4c240962bf146 upstream.

    option driver, added VID/PID for Telit UE910v2 modem

    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: serial: ftdi_sio: add id for Brainboxes serial cards

    commit efe26e16b1d93ac0085e69178cc18811629e8fc5 upstream.

    Custom VID/PIDs for Brainboxes cards as reported in
    https://bugzilla.redhat.com/show_bug.cgi?id=1071914

    Signed-off-by: Michele Baldessari <michele@acksyn.org>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: cp210x: Add 8281 (Nanotec Plug & Drive)

    commit 72b3007951010ce1bbf950e23b19d9839fa905a5 upstream.

    Signed-off-by: Tristan Bruns <tristan@tristanbruns.de>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver

    commit 895d240d1db0b2736d779200788e4c4aea28a0c6 upstream.

    By specifying NO_UNION_NORMAL the ACM driver does only use the first two
    USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA
    interfaces are left to the USB serial driver.

    Signed-off-by: Michael Ulbricht <michael.ulbricht@systec-electronic.com>
    Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
    Signed-off-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()

    commit 7848a4bf51b34f41fcc9bd77e837126d99ae84e3 upstream.

    soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892 "mm:
    hugetlb: fix softlockup when a large number of hugepages are freed." can
    happen in return_unused_surplus_pages(), so let's fix it.

    Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e7d5173a89ba3931ccf5e589123dd3527349f67
Author: Helge Deller <deller@gmx.de>
Date:   Sun Apr 13 00:03:55 2014 +0200

    parisc: fix epoll_pwait syscall on compat kernel

    commit ab3e55b119c9653b19ea4edffb86f04db867ac98 upstream.

    This bug was detected with the libio-epoll-perl debian package where the
    test case IO-Ppoll-compat.t failed.

    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5079e95d5722b324f8901e976b948e45a84e6bb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun May 18 05:26:09 2014 -0700

    Linux 3.4.91

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

    tgafb: fix mode setting with fbset

    commit 624966589041deb32a2626ee2e176e8274581101 upstream.

    Mode setting in the TGA driver is broken for these reasons:

    - info->fix.line_length is set just once in tgafb_init_fix function. If
      we change videomode, info->fix.line_length is not recalculated - so
      the video mode is changed but the screen is corrupted because of wrong
      info->fix.line_length.

    - info->fix.smem_len is set in tgafb_init_fix to the size of the default
      video mode (640x480). If we set a higher resolution,
      info->fix.smem_len is smaller than the current screen size, preventing
      the userspace program from mapping the framebuffer.

    This patch fixes it:

    - info->fix.line_length initialization is moved to tgafb_set_par so that
      it is recalculated with each mode change.

    - info->fix.smem_len is set to a fixed value representing the real
      amount of video ram (the values are taken from xfree86 driver).

    - add a check to tgafb_check_var to prevent us from setting a videomode
      that doesn't fit into videoram.

    - in tgafb_register, tgafb_init_fix is moved upwards, to be called
      before fb_find_mode (because fb_find_mode already needs the videoram
      size set in tgafb_init_fix).

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    powerpc: Add vr save/restore functions

    commit 8fe9c93e7453e67b8bd09f263ec1bb0783c733fc upstream.

    GCC 4.8 now generates out-of-line vr save/restore functions when
    optimizing for size.  They are needed for the raid6 altivec support.

    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tracepoint: Do not waste memory on mods with no tracepoints

    commit 7dec935a3aa04412cba2cebe1524ae0d34a30c24 upstream.

    No reason to allocate tp_module structures for modules that have no
    tracepoints. This just wastes memory.

    Fixes: b75ef8b44b1c "Tracepoint: Dissociate from module mutex"
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    netfilter: Can't fail and free after table replacement

    commit c58dd2dd443c26d856a168db108a0cd11c285bf3 upstream.

    All xtables variants suffer from the defect that the copy_to_user()
    to copy the counters to user memory may fail after the table has
    already been exchanged and thus exposed. Return an error at this
    point will result in freeing the already exposed table. Any
    subsequent packet processing will result in a kernel panic.

    We can't copy the counters before exposing the new tables as we
    want provide the counter state after the old table has been
    unhooked. Therefore convert this into a silent error.

    Cc: Florian Westphal <fw@strlen.de>
    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6bcbc5eddcd3d833187733e36fc5c62f946289f
Author: Joe Perches <joe@perches.com>
Date:   Sun May 13 21:56:25 2012 +0000

    net: Add net_ratelimited_function and net_<level>_ratelimited macros

    commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream.

    __ratelimit() can be considered an inverted bool test because
    it returns true when not ratelimited.  Several tests in the
    kernel tree use this __ratelimit() function incorrectly.

    No net_ratelimit uses are incorrect currently though.

    Most uses of net_ratelimit are to log something via printk or
    pr_<level>.

    In order to minimize the uses of net_ratelimit, and to start
    standardizing the code style used for __ratelimit() and net_ratelimit(),
    add a net_ratelimited_function() macro and net_<level>_ratelimited()
    logging macros similar to pr_<level>_ratelimited that use the global
    net_ratelimit instead of a static per call site "struct ratelimit_state".

    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len

    commit 223b02d923ecd7c84cf9780bb3686f455d279279 upstream.

    "len" contains sizeof(nf_ct_ext) and size of extensions. In a worst
    case it can contain all extensions. Bellow you can find sizes for all
    types of extensions. Their sum is definitely bigger than 256.

    nf_ct_ext_types[0]->len = 24
    nf_ct_ext_types[1]->len = 32
    nf_ct_ext_types[2]->len = 24
    nf_ct_ext_types[3]->len = 32
    nf_ct_ext_types[4]->len = 152
    nf_ct_ext_types[5]->len = 2
    nf_ct_ext_types[6]->len = 16
    nf_ct_ext_types[7]->len = 8

    I have seen "len" up to 280 and my host has crashes w/o this patch.

    The right way to fix this problem is reducing the size of the ecache
    extension (4) and Florian is going to do this, but these changes will
    be quite large to be appropriate for a stable tree.

    Fixes: 5b423f6a40a0 (netfilter: nf_conntrack: fix racy timer handling with reliable)
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    blktrace: fix accounting of partially completed requests

    commit af5040da01ef980670b3741b3e10733ee3e33566 upstream.

    trace_block_rq_complete does not take into account that request can
    be partially completed, so we can get the following incorrect output
    of blkparser:

      C   R 232 + 240 [0]
      C   R 240 + 232 [0]
      C   R 248 + 224 [0]
      C   R 256 + 216 [0]

    but should be:

      C   R 232 + 8 [0]
      C   R 240 + 8 [0]
      C   R 248 + 8 [0]
      C   R 256 + 8 [0]

    Also, the whole output summary statistics of completed requests and
    final throughput will be incorrect.

    This patch takes into account real completion size of the request and
    fixes wrong completion accounting.

    Signed-off-by: Roman Pen <r.peniaev@gmail.com>
    CC: Steven Rostedt <rostedt@goodmis.org>
    CC: Frederic Weisbecker <fweisbec@gmail.com>
    CC: Ingo Molnar <mingo@redhat.com>
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit deb3f1a9f9c42031eec6f088c128dc4a032ccfa2
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Sat May 3 14:04:59 2014 +0200

    n_tty: Fix n_tty_write crash when echoing in raw mode

    commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream.

    The tty atomic_write_lock does not provide an exclusion guarantee for
    the tty driver if the termios settings are LECHO & !OPOST.  And since
    it is unexpected and not allowed to call TTY buffer helpers like
    tty_insert_flip_string concurrently, this may lead to crashes when
    concurrect writers call pty_write. In that case the following two
    writers:
    * the ECHOing from a workqueue and
    * pty_write from the process
    race and can overflow the corresponding TTY buffer like follows.

    If we look into tty_insert_flip_string_fixed_flag, there is:
      int space = __tty_buffer_request_room(port, goal, flags);
      struct tty_buffer *tb = port->buf.tail;
      ...
      memcpy(char_buf_ptr(tb, tb->used), chars, space);
      ...
      tb->used += space;

    so the race of the two can result in something like this:
                  A                                B
    __tty_buffer_request_room
                                      __tty_buffer_request_room
    memcpy(buf(tb->used), ...)
    tb->used += space;
                                      memcpy(buf(tb->used), ...) ->BOOM

    B's memcpy is past the tty_buffer due to the previous A's tb->used
    increment.

    Since the N_TTY line discipline input processing can output
    concurrently with a tty write, obtain the N_TTY ldisc output_lock to
    serialize echo output with normal tty writes.  This ensures the tty
    buffer helper tty_insert_flip_string is not called concurrently and
    everything is fine.

    Note that this is nicely reproducible by an ordinary user using
    forkpty and some setup around that (raw termios + ECHO). And it is
    present in kernels at least after commit
    d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
    use the normal buffering logic) in 2.6.31-rc3.

    js: add more info to the commit log
    js: switch to bool
    js: lock unconditionally
    js: lock only the tty->ops->write call

    References: CVE-2014-0196
    Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: output_lock is a member of struct tty_struct]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

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

    SCSI: megaraid: missing bounds check in mimd_to_kioc()

    commit 3de2260140417759c669d391613d583baf03b0cf upstream.

    pthru32->dataxferlen comes from the user so we need to check that it's
    not too large so we don't overflow the buffer.

    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Sumit Saxena <sumit.saxena@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c7ee4a874162f7409e8435a7536c801f8e6d0ad
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 13 14:11:45 2014 +0200

    Linux 3.4.90

commit 2b859cb9b052ad94ba895d94a907422af06c99da
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Mar 28 02:15:02 2014 -0400

    dm thin: fix dangling bio in process_deferred_bios error path

    commit fe76cd88e654124d1431bb662a0fc6e99ca811a5 upstream.

    If unable to ensure_next_mapping() we must add the current bio, which
    was removed from the @bios list via bio_list_pop, back to the
    deferred_bios list before all the remaining @bios.

    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d296c5e5dc28da6a0914958132d2fdc3d65866a
Author: Giacomo Comes <comes@naic.edu>
Date:   Thu Apr 3 14:13:55 2014 -0400

    Skip intel_crt_init for Dell XPS 8700

    commit 10b6ee4a87811a110cb01eaca01eb04da6801baf upstream.

    The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port.
    The call intel_crt_init freeze the machine, so skip such call.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559
    Signed-off-by: Giacomo Comes <comes at naic.edu>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e656d5cdf6f41a4448d232b77e2cd63d1b428bf
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 5 17:53:50 2013 +0300

    mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes()

    commit b4c233057771581698a13694ab6f33b48ce837dc upstream.

    We always put a NUL terminator one space past the end of the "vendor"
    buffer.  Walter Harms also pointed out that this should just use
    kstrndup().

    Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL')

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57f5f55ec489f2fd5ad0298723c0f27662a33959
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 17 23:03:08 2014 +0300

    mtd: nuc900_nand: NULL dereference in nuc900_nand_enable()

    commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream.

    Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR"
    which is NULL and not a valid register.

    Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tgafb: fix data copying

    commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream.

    The functions for data copying copyarea_foreward_8bpp and
    copyarea_backward_8bpp are buggy, they produce screen corruption.

    This patch fixes the functions and moves the logic to one function
    "copyarea_8bpp". For simplicity, the function only handles copying that
    is aligned on 8 pixes. If we copy an unaligned area, generic function
    cfb_copyarea is used.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e3070b7d1619394edfe79d1405832917d56d47d
Author: Marek Vasut <marex@denx.de>
Date:   Mon Mar 24 03:38:10 2014 +0100

    gpio: mxs: Allow for recursive enable_irq_wake() call

    commit a585f87c863e4e1d496459d382b802bf5ebe3717 upstream.

    The scenario here is that someone calls enable_irq_wake() from somewhere
    in the code. This will result in the lockdep producing a backtrace as can
    be seen below. In my case, this problem is triggered when using the wl1271
    (TI WlCore) driver found in drivers/net/wireless/ti/ .

    The problem cause is rather obvious from the backtrace, but let's outline
    the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
    which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
    calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
    grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
    irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
    marked as recursive, lockdep will spew the stuff below.

    We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
    fix the spew.

     =============================================
     [ INFO: possible recursive locking detected ]
     3.10.33-00012-gf06b763-dirty #61 Not tainted
     ---------------------------------------------
     kworker/0:1/18 is trying to acquire lock:
      (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88

     but task is already holding lock:
      (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88

     other info that might help us debug this:
      Possible unsafe locking scenario:

            CPU0
            ----
       lock(&irq_desc_lock_class);
       lock(&irq_desc_lock_class);

      *** DEADLOCK ***

      May be due to missing lock nesting notation

     3 locks held by kworker/0:1/18:
      #0:  (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4
      #1:  ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4
      #2:  (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88

     stack backtrace:
     CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
     Workqueue: events request_firmware_work_func
     [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14)
     [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64)
     [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104)
     [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58)
     [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88)
     [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4)
     [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24)
     [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44)
     [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4)
     [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c)
     [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58)
     [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4)
     [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394)
     [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0)
     [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34)
     wlcore: loaded

    Signed-off-by: Marek Vasut <marex@denx.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4155a169170ea865b2d652601e17c0e0df42a3e5
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Mar 4 16:53:51 2014 -0600

    rtlwifi: rtl8192se: Fix too long disable of IRQs

    commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.

    In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
    rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
    <olivier@trillion01.com> fixed a problem caused by an extra long disabling
    of interrupts. This patch makes the same fix for rtl8192se.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 021a505d0326f39d209288c554c293ad687f0c01
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Mar 4 16:53:50 2014 -0600

    rtlwifi: rtl8192cu: Fix too long disable of IRQs

    commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.

    In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
    rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
    <olivier@trillion01.com> fixed a problem caused by an extra long disabling
    of interrupts. This patch makes the same fix for rtl8192cu.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66276245ecac0f777b906f3fdb734368f9048754
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Apr 15 08:44:12 2014 -0400

    locks: allow __break_lease to sleep even when break_time is 0

    commit 4991a628a789dc5954e98e79476d9808812292ec upstream.

    A fl->fl_break_time of 0 has a special meaning to the lease break code
    that basically means "never break the lease". knfsd uses this to ensure
    that leases don't disappear out from under it.

    Unfortunately, the code in __break_lease can end up passing this value
    to wait_event_interruptible as a timeout, which prevents it from going
    to sleep at all. This causes __break_lease to spin in a tight loop and
    causes soft lockups.

    Fix this by ensuring that we pass a minimum value of 1 as a timeout
    instead.

    Cc: J. Bruce Fields <bfields@fieldses.org>
    Reported-by: Terry Barnaby <terry1@beam.ltd.uk>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3390d1dca5e9d131dc1bcc9a8c969936582f922e
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 17 11:48:21 2014 -0700

    libata/ahci: accommodate tag ordered controllers

    commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.

    The AHCI spec allows implementations to issue commands in tag order
    rather than FIFO order:

    	5.3.2.12 P:SelectCmd
    	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
    	or HBA selects the command to issue that has had the
    	PxCI bit set to '1' longer than any other command
    	pending to be issued.

    The result is that commands posted sequentially (time-wise) may play out
    of sequence when issued by hardware.

    This behavior has likely been hidden by drives that arrange for commands
    to complete in issue order.  However, it appears recent drives (two from
    different vendors that we have found so far) inflict out-of-order
    completions as a matter of course.  So, we need to take care to maintain
    ordered submission, otherwise we risk triggering a drive to fall out of
    sequential-io automation and back to random-io processing, which incurs
    large latency and degrades throughput.

    This issue was found in simple benchmarks where QD=2 seq-write
    performance was 30-50% *greater* than QD=32 seq-write performance.

    Tagging for -stable and making the change globally since it has a low
    risk-to-reward ratio.  Also, word is that recent versions of an unnamed
    OS also does it this way now.  So, drives in the field are already
    experienced with this tag ordering scheme.

    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
    Reviewed-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55df559d2ae37ec1e60680bc2bb2355d4925f3dc
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Sat Apr 5 18:08:25 2014 +0200

    b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR

    commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream.

    Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
    functions isn't safe. On my machine it causes delayed (!) CPU exception:

    Disabling lock debugging due to kernel taint
    mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
    mce: [Hardware Error]: TSC 164083803dc
    mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
    mce: [Hardware Error]: Run the above through 'mcelog --ascii'
    mce: [Hardware Error]: Machine check: Processor context corrupt
    Kernel panic - not syncing: Fatal machine check on current CPU
    Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ea91325838033fa1f51aaab39de32031162bac2
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:41:59 2014 -0500

    mach64: fix cursor when character width is not a multiple of 8 pixels

    commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream.

    This patch fixes the hardware cursor on mach64 when font width is not a
    multiple of 8 pixels.

    If you load such a font, the cursor is expanded to the next 8-byte
    boundary and a part of the next character after the cursor is not
    visible.
    For example, when you load a font with 12-pixel width, the cursor width
    is 16 pixels and when the cursor is displayed, 4 pixels of the next
    character are not visible.

    The reason is this: atyfb_cursor is called with proper parameters to
    load an image that is 12-pixel wide. However, the number is aligned on
    the next 8-pixel boundary on the line
    "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole
    function acts as it is was loading a 16-pixel image.

    This patch fixes it so that the value written to the framebuffer is
    padded with 0xaaaa (the transparent pattern) when the image size it not
    a multiple of 8 pixels. The transparent pattern causes that the cursor
    will not interfere with the next character.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d759fc2c1becca859634ab291b55dad30bbafac8
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:41:09 2014 -0500

    mach64: use unaligned access

    commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream.

    This patch fixes mach64 to use unaligned access to the font bitmap.

    This fixes unaligned access warning on sparc64 when 14x8 font is loaded.

    On x86(64), unaligned access is handled in hardware, so both functions
    le32_to_cpup and get_unaligned_le32 perform the same operation.

    On RISC machines, unaligned access is not handled in hardware, so we
    better use get_unaligned_le32 to avoid the unaligned trap and warning.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b59d0695467116c9682dd96a4afca6cb564f5e0a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:39:04 2014 -0500

    matroxfb: restore the registers M_ACCESS and M_PITCH

    commit a772d4736641ec1b421ad965e13457c17379fc86 upstream.

    When X11 is running and the user switches back to console, the card
    modifies the content of registers M_MACCESS and M_PITCH in periodic
    intervals.

    This patch fixes it by restoring the content of these registers before
    issuing any accelerator command.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90da8fabd2f0026dfe844931568f9260a9982e7a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:39:29 2014 -0500

    framebuffer: fix cfb_copyarea

    commit 00a9d699bc85052d2d3ed56251cd928024ce06a3 upstream.

    The function cfb_copyarea is buggy when the copy operation is not aligned on
    long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines).

    How to reproduce:
    - use x86-64 machine
    - use a framebuffer driver without acceleration (for example uvesafb)
    - set the framebuffer to 8-bit depth
    	(for example fbset -a 1024x768-60 -depth 8)
    - load a font with character width that is not a multiple of 8 pixels
    	note: the console-tools package cannot load a font that has
    	width different from 8 pixels. You need to install the packages
    	"kbd" and "console-terminus" and use the program "setfont" to
    	set font width (for example: setfont Uni2-Terminus20x10)
    - move some text left and right on the bash command line and you get a
    	screen corruption

    To expose more bugs, put this line to the end of uvesafb_init_info:
    info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST;
    - Now framebuffer console will use cfb_copyarea for console scrolling.
    You get a screen corruption when console is scrolled.

    This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this
    patch, console scrolling in 8-bit depth with a font width that is not a
    multiple of 8 pixels works fine.

    The cfb_copyarea code was very buggy and it looks like it was written
    and never tried with non-8-pixel font.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a56d02acfe17494e4da931685f6bea50d4f17da
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Mar 27 18:14:40 2014 +0100

    crypto: ghash-clmulni-intel - use C implementation for setkey()

    commit 8ceee72808d1ae3fb191284afc2257a2be964725 upstream.

    The GHASH setkey() function uses SSE registers but fails to call
    kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and
    then having to deal with the restriction that they cannot be called from
    interrupt context, move the setkey() implementation to the C domain.

    Note that setkey() does not use any particular SSE features and is not
    expected to become a performance bottleneck.

    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Acked-by: H. Peter Anvin <hpa@linux.intel.com>
    Fixes: 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation)
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4722c7eb828716fced6159ba484aeeecfbc910e1
Author: Tyler Stachecki <tstache1@binghamton.edu>
Date:   Fri Apr 25 16:41:04 2014 -0400

    mpt2sas: Don't disable device twice at suspend.

    commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream.

    On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
    in turn calls pci_disable_device if the device is enabled prior to
    suspending. However, _scsih_suspend also calls pci_disable_device
    itself.

    Thus, in the event that the device is enabled prior to suspending,
    pci_disable_device will be called twice. This patch removes the
    duplicate call to pci_disable_device in _scsi_suspend as it is both
    unnecessary and results in a kernel oops.

    Signed-off-by: Tyler Stachecki <tstache1@binghamton.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0db45fc336f0ba5e441e31cddd2c301bc8de89d
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Thu Mar 13 11:23:38 2014 +1030

    virtio_balloon: don't softlockup on huge balloon changes.

    commit 1f74ef0f2d7d692fcd615621e0e734c3e7771413 upstream.

    When adding or removing 100G from a balloon:

        BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367]

    We have a wait_event_interruptible(), but the condition is always true
    (more ballooning to do) so we don't ever sleep.  We also have a
    wait_event() for the host to ack, but that is also always true as QEMU
    is synchronous for balloon operations.

    Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7c774a316d15bedcb2671070b35c0eadf9db0a9
Author: Huacai Chen <chenhc@lemote.com>
Date:   Sat Mar 22 17:21:44 2014 +0800

    MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume()

    commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream.

    The original MIPS hibernate code flushes cache and TLB entries in
    swsusp_arch_resume(). But they are removed in Commit 44eeab67416711
    (MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross-
    CPU flush is surely unnecessary because all but the local CPU have
    already been disabled. But a local flush (at least the TLB flush) is
    needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is
    very easy to produce a kernel panic (kernel page fault, or unaligned
    access). The root cause is E1000E driver use vzalloc_node() to allocate
    pages, the stale TLB entries of the booting kernel will be misused by
    the resumed target kernel.

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: Aurelien Jarno <aurelien@aurel32.net>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Patchwork: https://patchwork.linux-mips.org/patch/6643/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d89915aed21a9d3a23687a153d522c9be5273818
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Mon Apr 28 19:05:21 2014 +1200

    floppy: don't write kernel-only members to FDRAWCMD ioctl output

    commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream.

    Do not leak kernel-only floppy_raw_cmd structure members to userspace.
    This includes the linked-list pointer and the pointer to the allocated
    DMA space.

    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39ff76b2f38b56dd5429f29f411823182e4088cd
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Mon Apr 28 19:05:20 2014 +1200

    floppy: ignore kernel-only members in FDRAWCMD ioctl input

    commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream.

    Always clear out these floppy_raw_cmd struct members after copying the
    entire structure from userspace so that the in-kernel version is always
    valid and never left in an interdeterminate state.

    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f498922f066621cea2e7fb544a27eae46edc0a6
Author: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
Date:   Fri May 2 18:58:24 2014 -0400

    drivers/tty/hvc: don't free hvc_console_setup after init

    commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream.

    When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest,
    hvc console is setup within a kthread. However, that will cause SEGV
    and the boot will fail when the driver is builtin to the kernel,
    because currently hvc_console_setup() is annotated with '__init'. This
    patch removes '__init' to boot the guest successfully with 'console=hvc0'.

    Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64fd64e3406900bbaf76220db7564896191be9e5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 6 07:52:14 2014 -0700

    Linux 3.4.89

commit fbdbfa11685a884ccc839ccff54adb7e59c9c214
Author: Aaron Sanders <aaron.sanders@hp.com>
Date:   Mon Mar 31 15:54:21 2014 +0200

    USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

    commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream.

    Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:

    LD960: 03f0:0B39
    LCM220: 03f0:3139
    LCM960: 03f0:3239

    [ Johan: fix indentation and sort PIDs numerically ]

    Signed-off-by: Aaron Sanders <aaron.sanders@hp.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4ebac55bfa0fd3eadb577a47baa97bb516bd799
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Apr 12 12:45:25 2014 -0400

    ext4: use i_size_read in ext4_unaligned_aio()

    commit 6e6358fc3c3c862bfe9a5bc029d3f8ce43dc9765 upstream.

    We haven't taken i_mutex yet, so we need to use i_size_read().

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acebf789e95701f958f43eb9a14a7f16d83bf362
Author: alex chen <alex.chen@huawei.com>
Date:   Thu Apr 3 14:47:05 2014 -0700

    ocfs2: do not put bh when buffer_uptodate failed

    commit f7cf4f5bfe073ad792ab49c04f247626b3e38db6 upstream.

    Do not put bh when buffer_uptodate failed in ocfs2_write_block and
    ocfs2_write_super_or_backup, because it will put bh in b_end_io.
    Otherwise it will hit a warning "VFS: brelse: Trying to free free
    buffer".

    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Acked-by: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e11ffd8c0e4711bc160da8106daa406bc793d82
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Apr 3 14:46:51 2014 -0700

    ocfs2: dlm: fix recovery hung

    commit ded2cf71419b9353060e633b59e446c42a6a2a09 upstream.

    There is a race window in dlm_do_recovery() between dlm_remaster_locks()
    and dlm_reset_recovery() when the recovery master nearly finish the
    recovery process for a dead node.  After the master sends FINALIZE_RECO
    message in dlm_remaster_locks(), another node may become the recovery
    master for another dead node, and then send the BEGIN_RECO message to
    all the nodes included the old master, in the handler of this message
    dlm_begin_reco_handler() of old master, dlm->reco.dead_node and
    dlm->reco.new_master will be set to the second dead node and the new
    master, then in dlm_reset_recovery(), these two variables will be reset
    to default value.  This will cause new recovery master can not finish
    the recovery process and hung, at last the whole cluster will hung for
    recovery.

    old recovery master:                                 new recovery master:
    dlm_remaster_locks()
                                                      become recovery master for
                                                      another dead node.
                                                      dlm_send_begin_reco_message()
    dlm_begin_reco_handler()
    {
     if (dlm->reco.state & DLM_RECO_STATE_FINALIZE) {
      return -EAGAIN;
     }
     dlm_set_reco_master(dlm, br->node_idx);
     dlm_set_reco_dead_node(dlm, br->dead_node);
    }
    dlm_reset_recovery()
    {
     dlm_set_reco_dead_node(dlm, O2NM_INVALID_NODE_NUM);
     dlm_set_reco_master(dlm, O2NM_INVALID_NODE_NUM);
    }
                                                      will hang in dlm_remaster_locks() for
                                                      request dlm locks info

    Before send FINALIZE_RECO message, recovery master should set
    DLM_RECO_STATE_FINALIZE for itself and clear it after the recovery done,
    this can break the race windows as the BEGIN_RECO messages will not be
    handled before DLM_RECO_STATE_FINALIZE flag is cleared.

    A similar race may happen between new recovery master and normal node
    which is in dlm_finalize_reco_handler(), also fix it.

    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18c44f19f3046d4a805b3ab93479b7e2af11ab58
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Apr 3 14:46:49 2014 -0700

    ocfs2: dlm: fix lock migration crash

    commit 34aa8dac482f1358d59110d5e3a12f4351f6acaa upstream.

    This issue was introduced by commit 800deef3f6f8 ("ocfs2: use
    list_for_each_entry where benefical") in 2007 where it replaced
    list_for_each with list_for_each_entry.  The variable "lock" will point
    to invalid data if "tmpq" list is empty and a panic will be triggered
    due to this.  Sunil advised reverting it back, but the old version was
    also not right.  At the end of the outer for loop, that
    list_for_each_entry will also set "lock" to an invalid data, then in the
    next loop, if the "tmpq" list is empty, "lock" will be an stale invalid
    data and cause the panic.  So reverting the list_for_each back and reset
    "lock" to NULL to fix this issue.

    Another concern is that this seemes can not happen because the "tmpq"
    list should not be empty.  Let me describe how.

    old lock resource owner(node 1):                                  migratation target(node 2):
    image there's lockres with a EX lock from node 2 in
    granted list, a NR lock from node x with convert_type
    EX in converting list.
    dlm_empty_lockres() {
     dlm_pick_migration_target() {
       pick node 2 as target as its lock is the first one
       in granted list.
     }
     dlm_migrate_lockres() {
       dlm_mark_lockres_migrating() {
         res->state |= DLM_LOCK_RES_BLOCK_DIRTY;
         wait_event(dlm->ast_wq, !dlm_lockres_is_dirty(dlm, res));
    	 //after the above code, we can not dirty lockres any more,
         // so dlm_thread shuffle list will not run
                                                                       downconvert lock from EX to NR
                                                                       upconvert lock from NR to EX
    <<< migration may schedule out here, then
    <<< node 2 send down convert request to convert type from EX to
    <<< NR, then send up convert request to convert type from NR to
    <<< EX, at this time, lockres granted list is empty, and two locks
    <<< in the converting list, node x up convert lock followed by
    <<< node 2 up convert lock.

    	 // will set lockres RES_MIGRATING flag, the following
    	 // lock/unlock can not run
         dlm_lockres_release_ast(dlm, res);
       }

       dlm_send_one_lockres()
                                                                     dlm_process_recovery_data()
                                                                       for (i=0; i<mres->num_locks; i++)
                                                                         if (ml->node == dlm->node_num)
                                                                           for (j = DLM_GRANTED_LIST; j <= DLM_BLOCKED_LIST; j++) {
                                                                            list_for_each_entry(lock, tmpq, list)
                                                                            if (lock) break; <<< lock is invalid as grant list is empty.
                                                                           }
                                                                           if (lock->ml.node != ml->node)
                                                                             BUG() >>> crash here
     }

    I see the above locks status from a vmcore of our internal bug.

    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
    Cc: Sunil Mushran <sunil.mushran@gmail.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdb20a91437568ef8a189c3caec248c9351b056a
Author: Liu Hua <sdu.liu@huawei.com>
Date:   Mon Apr 7 15:38:57 2014 -0700

    hung_task: check the value of "sysctl_hung_task_timeout_sec"

    commit 80df28476505ed4e6701c3448c63c9229a50c655 upstream.

    As sysctl_hung_task_timeout_sec is unsigned long, when this value is
    larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in
    watchdog will return immediately without sleep and with print :

      schedule_timeout: wrong timeout value ffffffffffffff83

    and then the funtion watchdog will call schedule_timeout_interruptible
    again and again.  The screen will be filled with

    	"schedule_timeout: wrong timeout value ffffffffffffff83"

    This patch does some check and correction in sysctl, to let the function
    schedule_timeout_interruptible allways get the valid parameter.

    Signed-off-by: Liu Hua <sdu.liu@huawei.com>
    Tested-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33409ba4c75cf0835c43af7ecf1de5b965661504
Author: Mizuma, Masayoshi <m.mizuma@jp.fujitsu.com>
Date:   Mon Apr 7 15:37:54 2014 -0700

    mm: hugetlb: fix softlockup when a large number of hugepages are freed.

    commit 55f67141a8927b2be3e51840da37b8a2320143ed upstream.

    When I decrease the value of nr_hugepage in procfs a lot, softlockup
    happens.  It is because there is no chance of context switch during this
    process.

    On the other hand, when I allocate a large number of hugepages, there is
    some chance of context switch.  Hence softlockup doesn't happen during
    this process.  So it's necessary to add the context switch in the
    freeing process as same as allocating process to avoid softlockup.

    When I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing
    process occupied a CPU over 150 seconds and following softlockup message
    appeared twice or more.

    $ echo 6000000 > /proc/sys/vm/nr_hugepages
    $ cat /proc/sys/vm/nr_hugepages
    6000000
    $ grep ^Huge /proc/meminfo
    HugePages_Total:   6000000
    HugePages_Free:    6000000
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    $ echo 0 > /proc/sys/vm/nr_hugepages

    BUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ...
    Pid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1
    Call Trace:
      free_pool_huge_page+0xb8/0xd0
      set_max_huge_pages+0x128/0x190
      hugetlb_sysctl_handler_common+0x113/0x140
      hugetlb_sysctl_handler+0x1e/0x20
      proc_sys_call_handler+0x97/0xd0
      proc_sys_write+0x14/0x20
      vfs_write+0xb8/0x1a0
      sys_write+0x51/0x90
      __audit_syscall_exit+0x265/0x290
      system_call_fastpath+0x16/0x1b

    I have not confirmed this problem with upstream kernels because I am not
    able to prepare the machine equipped with 12TB memory now.  However I
    confirmed that the amount of decreasing hugepages was directly
    proportional to the amount of required time.

    I measured required times on a smaller machine.  It showed 130-145
    hugepages decreased in a millisecond.

      Amount of decreasing     Required time      Decreasing rate
      hugepages                     (msec)         (pages/msec)
      ------------------------------------------------------------
      10,000 pages == 20GB         70 -  74          135-142
      30,000 pages == 60GB        208 - 229          131-144

    It means decrement of 6TB hugepages will trigger softlockup with the
    default threshold 20sec, in this decreasing rate.

    Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 591f2984bc1920d5849e5269f29b1c271887b8c9
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Thu Apr 3 14:46:20 2014 -0700

    sh: fix format string bug in stack tracer

    commit a0c32761e73c9999cbf592b702f284221fea8040 upstream.

    Kees reported the following error:

       arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
       arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no format arguments [-Werror=format-security]

    Use the "%s" format so that it's impossible to interpret 'data' as a
    format string.

    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Reported-by: Kees Cook <keescook@chromium.org>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6d35f2b5b2c1a5cefea8866031a4fed3fdc4941
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Mar 12 11:30:38 2014 -0400

    USB: unbind all interfaces before rebinding any

    commit 6aec044cc2f5670cf3b143c151c8be846499bd15 upstream.

    When a driver doesn't have pre_reset, post_reset, or reset_resume
    methods, the USB core unbinds that driver when its device undergoes a
    reset or a reset-resume, and then rebinds it afterward.

    The existing straightforward implementation can lead to problems,
    because each interface gets unbound and rebound before the next
    interface is handled.  If a driver claims additional interfaces, the
    claim may fail because the old binding instance may still own the
    additional interface when the new instance tries to claim it.

    This patch fixes the problem by first unbinding all the interfaces
    that are marked (i.e., their needs_binding flag is set) and then
    rebinding all of them.

    The patch also makes the helper functions in driver.c a little more
    uniform and adjusts some out-of-date comments.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: "Poulain, Loic" <loic.poulain@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1535a521222015e194a040ecd91b6ab2d8f2474c
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Tue Jan 14 16:03:37 2014 -0500

    hvc: ensure hvc_init is only ever called once in hvc_console.c

    commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.

    Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
    khcvd thread") moved the call of hvc_init from being a device_initcall
    into hvc_alloc, and used a non-null hvc_driver as indication of whether
    hvc_init had already been called.

    The problem with this is that hvc_driver is only assigned a value
    at the bottom of hvc_init, and so there is a window where multiple
    hvc_alloc calls can be in progress at the same time and hence try
    and call hvc_init multiple times.  Previously the use of device_init
    guaranteed that hvc_init was only called once.

    This manifests itself as sporadic instances of two hvc_init calls
    racing each other, and with the loser of the race getting -EBUSY
    from tty_register_driver() and hence that virtual console fails:

        Couldn't register hvc console driver
        virtio-ports vport0p1: error -16 allocating hvc for port

    Here we add an atomic_t to guarantee we'll never run hvc_init twice.

    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
    Reported-by: Jim Somerville <Jim.Somerville@windriver.com>
    Tested-by: Jim Somerville <Jim.Somerville@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fa71da9969efe4bfa066c1648ca2e3af71c8032
Author: Huang Rui <ray.huang@amd.com>
Date:   Tue Jan 7 17:45:50 2014 +0800

    usb: dwc3: fix wrong bit mask in dwc3_event_devt

    commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream.

    Around DWC USB3 2.30a release another bit has been added to the
    Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield.

    Because of that, what used to be 8 bits long, has become 9 bits long.

    Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of
    Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
    not 8 bits. And the following reserved field uses [31:25] bits not
    [31:24] bits, and it has 7 bits.

    So in dwc3_event_devt, the bit mask should be:
    event_info	[24:16]		9 bits
    reserved31_25	[31:25]		7 bits

    This patch makes sure that newer core releases will work fine with
    Linux and that we will decode the event information properly on new
    core releases.

    [ balbi@ti.com : improve commit log a bit ]

    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e865610fc7b007992ad0b701d3d29feeb4c4cb30
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Fri Apr 25 19:20:16 2014 +0300

    usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

    commit 01bb59ebffdec314da8da66266edf29529372f9b upstream.

    When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
    warning:
    drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
    but not used [-Wunused-function]

    Instead of creating nested #ifdefs, this patch fixes it by defining the
    xHCI PCI stubs as inline.

    This warning has been in since 3.2 kernel and was
    caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
    "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
    until 3.13 when a configuration with these options was tried

    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d89d17c3ca8a1f23f332842507c2e550724b5388
Author: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Date:   Fri Apr 25 19:20:15 2014 +0300

    xhci: extend quirk for Renesas cards

    commit 6db249ebefc6bf5c39f35dfaacc046d8ad3ffd70 upstream.

    After suspend another Renesas PCI-X USB 3.0 card doesn't work.
    [root@fedora-20 ~]# lspci -vmnnd 1912:
    Device:	03:00.0
    Class:	USB controller [0c03]
    Vendor:	Renesas Technology Corp. [1912]
    Device:	uPD720202 USB 3.0 Host Controller [0015]
    SVendor:	Renesas Technology Corp. [1912]
    SDevice:	uPD720202 USB 3.0 Host Controller [0015]
    Rev:	02
    ProgIf:	30

    This patch should be applied to stable kernel 3.14 that contain
    the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d
    "xhci: Fix resume issues on Renesas chips in Samsung laptops"

    Reported-and-tested-by: Anatoly Kharchenko <rfr-bugs@yandex.ru>
    Reference: http://redmine.russianfedora.pro/issues/1315
    Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76463b282638f9d71eba20bb162dcff12b9b7836
Author: supriya karanth <supriya.karanth@stericsson.com>
Date:   Thu Dec 6 11:12:48 2012 +0530

    usb: musb: set TXMAXP and AUTOSET for full speed bulk in device mode

    commit bb3a2ef2eb8cfaea335dcb3426350df7f3d48069 upstream.

    The TXMAXP register is not set correctly for full speed bulk case
    when the can_bulk_split() is used. Without this PIO transfers will
    not take place correctly

    The "mult" factor needs to be updated correctly for the
    can_bulk_split() case

    The AUTOSET bit in the TXCSR is not being set if the "mult"
    factor is greater than 0 for the High Bandwidth ISO case.
    But the "mult" factor is also greater than 0 in case of Full speed
    bulk transfers with the packet splitting in TXMAXP register

    Without the AUTOSET the DMA transfers will not progress in mode1

    [ balbi@ti.com : add braces to both branches ]

    Signed-off-by: supriya karanth <supriya.karanth@stericsson.com>
    Signed-off-by: Praveena NADAHALLY <praveen.nadahally@stericsson.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Cc: ian coolidge <iancoolidge@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a2d50c4546f7dbeeefbd66ad4b652cec11afc38
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Wed Apr 2 14:40:26 2014 -0400

    reiserfs: fix race in readdir

    commit 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44 upstream.

    jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)

    The -ENOENT is due to readdir calling dir_emit on the same entry twice.

    If the dir_emit callback sleeps and the tree is changed underneath us,
    we won't be able to trust deh_offset(deh) anymore. We need to save
    next_pos before we might sleep so we can find the next entry.

    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db3cd7cdbe2948121cac5bc13abd83a481f843a3
Author: Andy Grover <agrover@redhat.com>
Date:   Fri Apr 4 16:44:37 2014 -0700

    target/tcm_fc: Fix use-after-free of ft_tpg

    commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream.

    ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
    tport when the tpg is being removed. Set this pointer in ft_tport_create,
    or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
    a deleted object.

    This patch sets tpg->tport in ft_tport_create, because that's what
    ft_del_tpg checks, and is the only way to get back to the tport to
    clear tport->tpg.

    The bug was occuring when:

    - lport created, tport (our per-lport, per-provider context) is
      allocated.
      tport->tpg = NULL
    - tpg created
    - a PRLI is received. ft_tport_create is called, tpg is found and
      tport->tpg is set
    - tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
      set, tport->tpg is not cleared and points at freed memory
    - Future calls to ft_tport_create return tport via first conditional,
      instead of searching for new tpg by calling ft_lport_find_tpg.
      tport->tpg is still invalid, and will access freed memory.

    see https://bugzilla.redhat.com/show_bug.cgi?id=1071340

    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9db9f50fb29763f248453c79e54fa617271aeda4
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Feb 19 23:32:14 2014 +0000

    iscsi-target: Fix ERL=2 ASYNC_EVENT connection pointer bug

    commit d444edc679e7713412f243b792b1f964e5cff1e1 upstream.

    This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message()
    where during ERL=2 connection recovery, a bogus conn_p pointer could
    end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION
    notifying the initiator that cmd->logout_cid has failed.

    The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with
    a bogus conn_p pointer in iscsit_build_conn_drop_async_message().

    Reported-by: Arshad Hussain <arshad.hussain@calsoftinc.com>
    Reported-by: santosh kulkarni <santosh.kulkarni@calsoftinc.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14ec8bdca200f05238bb88936764db47c1d2d8b4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 11 19:06:33 2014 +0300

    SCSI: arcmsr: upper 32 of dma address lost

    commit e2c70425f05219b142b3a8a9489a622c736db39d upstream.

    The original code always set the upper 32 bits to zero because it was
    doing a shift of the wrong variable.

    Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef3d7541e124979fa4a49be51e6cf38798d2968a
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Mon Apr 7 13:58:35 2014 -0400

    ib_srpt: Use correct ib_sg_dma primitives

    commit b076808051f2c80d38e03fb2f1294f525c7a446d upstream.

    The code was incorrectly using sg_dma_address() and
    sg_dma_len() instead of ib_sg_dma_address() and
    ib_sg_dma_len().

    This prevents srpt from functioning with the
    Intel HCA and indeed will corrupt memory
    badly.

    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Tested-by: Vinod Kumar <vinod.kumar@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d9a01db544bad3e9512787e6e851db0c1b640f1
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:25 2014 +0100

    IB/ehca: Returns an error on ib_copy_to_udata() failure

    commit 5bdb0f02add5994b0bc17494f4726925ca5d6ba1 upstream.

    In case of error when writing to userspace, function ehca_create_cq()
    does not set an error code before following its error path.

    This patch sets the error code to -EFAULT when ib_copy_to_udata()
    fails.

    This was caught when using spatch (aka. coccinelle)
    to rewrite call to ib_copy_{from,to}_udata().

    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cc5b547e8f498a2c8b1ab12af0719eae1486e57
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:26 2014 +0100

    IB/mthca: Return an error on ib_copy_to_udata() failure

    commit 08e74c4b00c30c232d535ff368554959403d0432 upstream.

    In case of error when writing to userspace, the function mthca_create_cq()
    does not set an error code before following its error path.

    This patch sets the error code to -EFAULT when ib_copy_to_udata() fails.

    This was caught when using spatch (aka. coccinelle)
    to rewrite call to ib_copy_{from,to}_udata().

    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c77a93d0329a65764db664b9e5935ee3551ec411
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Mon Mar 10 23:06:27 2014 +0100

    IB/nes: Return an error on ib_copy_from_udata() failure instead of NULL

    commit 9d194d1025f463392feafa26ff8c2d8247f71be1 upstream.

    In case of error while accessing to userspace memory, function
    nes_create_qp() returns NULL instead of an error code wrapped through
    ERR_PTR().  But NULL is not expected by ib_uverbs_create_qp(), as it
    check for error with IS_ERR().

    As page 0 is likely not mapped, it is going to trigger an Oops when
    the kernel will try to dereference NULL pointer to access to struct
    ib_qp's fields.

    In some rare cases, page 0 could be mapped by userspace, which could
    turn this bug to a vulnerability that could be exploited: the function
    pointers in struct ib_device will be under userspace total control.

    This was caught when using spatch (aka. coccinelle)
    to rewrite calls to ib_copy_{from,to}_udata().

    Link: https://www.gitorious.org/opteya/ib-hw-nes-create-qp-null
    Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci
    Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79dd62d6e09633778cc6af5645039775063f802b
Author: Dennis Dalessandro <dennis.dalessandro@intel.com>
Date:   Thu Feb 20 11:02:53 2014 -0500

    IB/ipath: Fix potential buffer overrun in sending diag packet routine

    commit a2cb0eb8a64adb29a99fd864013de957028f36ae upstream.

    Guard against a potential buffer overrun.  The size to read from the
    user is passed in, and due to the padding that needs to be taken into
    account, as well as the place holder for the ICRC it is possible to
    overflow the 32bit value which would cause more data to be copied from
    user space than is allocated in the buffer.

    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7007b971d8c86a5216c395bb65b45cf6854d69a
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Mar 10 14:17:55 2014 -0400

    nfsd4: fix setclientid encode size

    commit 480efaee085235bb848f1063f959bf144103c342 upstream.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09ac2f5e2b8a521aa185014b0cbdf018f58d5c34
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Feb 24 14:59:47 2014 -0500

    nfsd: notify_change needs elevated write count

    commit 9f67f189939eccaa54f3d2c9cf10788abaf2d584 upstream.

    Looks like this bug has been here since these write counts were
    introduced, not sure why it was just noticed now.

    Thanks also to Jan Kara for pointing out the problem.

    Reported-by: Matthew Rahtz <mrahtz@rapitasystems.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b9285404b1105dc6cb82c8a93939dbe9e581764
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Feb 3 16:31:42 2014 -0500

    nfsd4: fix test_stateid error reply encoding

    commit a11fcce1544df08c723d950ff0edef3adac40405 upstream.

    If the entire operation fails then there's nothing to encode.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fea6e0f044b4f6078b8633b3836fd9ba3966c70
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 28 16:05:15 2014 -0500

    nfsd4: buffer-length check for SUPPATTR_EXCLCREAT

    commit de3997a7eeb9ea286b15879fdf8a95aae065b4f7 upstream.

    This was an omission from 8c18f2052e756e7d5dea712fc6e7ed70c00e8a39
    "nfsd41: SUPPATTR_EXCLCREAT attribute".

    Cc: Benny Halevy <bhalevy@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a1a9cfbd99ee5d52d5c92c3ca4e8e9ca6ecfc56
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 28 16:01:04 2014 -0500

    nfsd4: session needs room for following op to error out

    commit 4c69d5855a16f7378648c5733632628fa10431db upstream.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6dc4056b4a476691dea4c2c8c1e1cbe56c4960f
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Apr 14 13:48:47 2014 -0400

    USB: fix crash during hotplug of PCI USB controller card

    commit a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 upstream.

    The code in hcd-pci.c that matches up EHCI controllers with their
    companion UHCI or OHCI controllers assumes that the private drvdata
    fields don't get set too early.  However, it turns out that this field
    gets set by usb_create_hcd(), before hcd-pci expects it, and this can
    result in a crash when two controllers are probed in parallel (as can
    happen when a new controller card is hotplugged).

    The companions_rwsem lock was supposed to prevent this sort of thing,
    but usb_create_hcd() is called outside the scope of the rwsem.

    A simple solution is to check that the root-hub pointer has been
    initialized as well as the drvdata field.  This doesn't happen until
    usb_add_hcd() is called; that call and the check are both protected by
    the rwsem.

    This patch should be applied to stable kernels from 3.10 onward.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Stefani Seibold <stefani@seibold.net>
    Tested-by: Stefani Seibold <stefani@seibold.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 047500f8a5a2434e43b12a62d4a55fde52c2d2b1
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Sun Mar 16 15:31:54 2014 -0700

    x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

    commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.

    The IRET instruction, when returning to a 16-bit segment, only
    restores the bottom 16 bits of the user space stack pointer.  We have
    a software workaround for that ("espfix") for the 32-bit kernel, but
    it relies on a nonzero stack segment base which is not available in
    32-bit mode.

    Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
    (no V86 mode), and most (if not quite all) 64-bit processors support
    virtualization for the users who really need it, simply reject
    attempts at creating a 16-bit segment when running on top of a 64-bit
    kernel.

    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 518a254a4c7e328d9ac4fa83d3ba97b6afc96a7c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Apr 16 14:49:33 2014 -0500

    staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0

    commit f764cd68d9036498f08fe8834deb6a367b5c2542 upstream.

    Zero-initializing ether_type masked that the ether type would never be
    obtained for 8021x packets and the comparison against eapol_type
    would always fail.

    Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2ebedf7dffe2da5672a05ad9d8b5972e1547592
Author: Himangi Saraogi <himangi774@gmail.com>
Date:   Wed Mar 5 04:59:57 2014 +0530

    staging:serqt_usb2: Fix sparse warning restricted __le16 degrades to integer

    commit abe5d64d1a74195a44cd14624f8178b9f48b7cc7 upstream.

    This patch fixes the following sparse warning :
    drivers/staging/serqt_usb2/serqt_usb2.c:727:40: warning: restricted __le16 degrades to integer

    Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d01be0d5316be17ba3a6e1588730fd594f33fb1
Author: David Fries <David@Fries.net>
Date:   Wed Jan 15 22:29:12 2014 -0600

    w1: fix w1_send_slave dropping a slave id

    commit 6b355b33a64fd6d8ead2b838ec16fb9b551f71e8 upstream.

    Previous logic,
    if (avail > 8) {
    	store slave;
    	return;
    }
    send data; clear;

    The logic error is, if there isn't space send the buffer and clear,
    but the slave wasn't added to the now empty buffer loosing that slave
    id.  It also should have been "if (avail >= 8)" because when it is 8,
    there is space.

    Instead, if there isn't space send and clear the buffer, then there is
    always space for the slave id.

    Signed-off-by: David Fries <David@Fries.net>
    Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7431c627824e5e1d26a6f940c591bbf9516a59b2
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:34 2014 +0100

    mfd: max8997: Fix possible NULL pointer dereference on i2c_new_dummy error

    commit 97dc4ed3fa377ec91bb60ba98b70d645c2099384 upstream.

    During probe the driver allocates dummy I2C devices for RTC, haptic and
    MUIC with i2c_new_dummy() but it does not check the return value of this
    calls.

    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().

    If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the
    probe for main MFD driver.

    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53ec18849f3a3d210545dd391b70dab8d9a3d8e6
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:35 2014 +0100

    mfd: max8998: Fix possible NULL pointer dereference on i2c_new_dummy error

    commit ed26f87b9f71693a1d1ee85f5e6209601505080f upstream.

    During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy() but it does not check the return value of this call.

    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().

    If i2c_new_dummy() fails for RTC device, fail also the probe for
    main MFD driver.

    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c3a56e391e5ec8084fa7024071fb4e491f2cac8
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Feb 11 11:03:33 2014 +0100

    mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error

    commit 96cf3dedc491d2f1f66cc26217f2b06b0c7b6797 upstream.

    During probe the driver allocates dummy I2C devices for RTC and ADC
    with i2c_new_dummy() but it does not check the return value of this
    calls.

    In case of error (i2c_new_device(): memory allocation failure or I2C
    address cannot be used) this function returns NULL which is later used
    by i2c_unregister_device().

    If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe
    for main MFD driver.

    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5c95d50da91c81acb74c22feb23b69db2b5a2ad
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 8 16:58:34 2014 +0200

    ALSA: ice1712: Fix boundary checks in PCM pointer ops

    commit 4f8e940095536bc002a81666a4107a581c84e9b9 upstream.

    PCM pointer callbacks in ice1712 driver check the buffer size boundary
    wrongly between bytes and frames.  This leads to PCM core warnings
    like:
       snd_pcm_update_hw_ptr0: 105 callbacks suppressed
       ALSA pcm_lib.c:352 BUG: pcmC3D0c:0, pos = 5461, buffer size = 5461, period size = 2730

    This patch fixes these checks to be placed after the proper unit
    conversions.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb54bca4b56490a603eef9f670213869d62df71e
Author: W. Trevor King <wking@tremily.us>
Date:   Sat Mar 29 17:47:24 2014 -0700

    ALSA: hda - Enable beep for ASUS 1015E

    commit a4b7f21d7b42b33609df3f86992a8deff80abfaf upstream.

    The `lspci -nnvv` output contains (wrapped for line length):

      00:1b.0 Audio device [0403]:
        Intel Corporation 7 Series/C210 Series Chipset Family
        High Definition Audio Controller [8086:1e20] (rev 04)
            Subsystem: ASUSTeK Computer Inc. Device [1043:115d]

    Signed-off-by: W. Trevor King <wking@tremily.us>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac3a67fda68d5b731b0afa91b92ae81aa9c96645
Author: Liu Hua <sdu.liu@huawei.com>
Date:   Fri Apr 18 07:45:36 2014 +0100

    ARM: 8030/1: ARM : kdump : add arch_crash_save_vmcoreinfo

    commit 56b700fd6f1e49149880fb1b6ffee0dca5be45fb upstream.

    For vmcore generated by LPAE enabled kernel, user space
    utility such as crash needs additional infomation to
    parse.

    So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
    i386 linux does.

    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Liu Hua <sdu.liu@huawei.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62530e64a9b3895367cd2a7d7144cbfda08a3f34
Author: Xiangyu Lu <luxiangyu@huawei.com>
Date:   Tue Apr 15 09:38:17 2014 +0100

    ARM: 8027/1: fix do_div() bug in big-endian systems

    commit 80bb3ef109ff40a7593d9481c17de9bbc4d7c0e2 upstream.

    In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result.

    When viewing ftrace record in big-endian ARM systems, we found that
    the timestamp errors:

    swapper-0   [001] 1325.970000:   0:120:R ==> [001]    16:120:R events/1
    events/1-16 [001] 1325.970000:   16:120:S ==> [001]    0:120:R swapper
    swapper-0   [000] 1325.1000000:  0:120:R   + [000]    15:120:R events/0
    swapper-0   [000] 1325.1000000:  0:120:R ==> [000]    15:120:R events/0
    swapper-0   [000] 1326.030000:   0:120:R   + [000]  1150:120:R sshd
    swapper-0   [000] 1326.030000:   0:120:R ==> [000]  1150:120:R sshd

    When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2".

    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Alex Wu <wuquanming@huawei.com>
    Signed-off-by: Xiangyu Lu <luxiangyu@huawei.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99530cb0629e6ae02801308246534576a2b08229
Author: Roger Quadros <rogerq@ti.com>
Date:   Thu Apr 10 10:18:17 2014 +0300

    ARM: OMAP3: hwmod data: Correct clock domains for USB modules

    commit c6c56697ae4bf1226263c19e8353343d7083f40e upstream.

    OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
    proper clock domains for USB Host and USB TLL modules.

    Gets rid of the following warnings during boot
     omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
     omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm

    Reported-by: Nishanth Menon <nm@ti.com>
    Cc: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Fixes: de231388cb80a8ef3e779bbfa0564ba0157b7377 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
    Cc: Keshava Munegowda <keshava_mgowda@ti.com>
    Cc: Partha Basak <parthab@india.ti.com>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb607900730e99cf735ccc8e8e2c074acd945c57
Author: Stefan Sørensen <stefan.sorensen@spectralink.com>
Date:   Thu Mar 6 16:27:15 2014 +0100

    ARM: OMAP2+: INTC: Acknowledge stuck active interrupts

    commit 698b48532539484b012fb7c4176b959d32a17d00 upstream.

    When an interrupt has become active on the INTC it will stay active
    until it is acked, even if masked or de-asserted. The
    INTC_PENDING_IRQn registers are however updated and since these are
    used by omap_intc_handle_irq to determine which interrupt to handle,
    it will never see the active interrupt. This will result in a storm of
    useless interrupts that is only stopped when another higher priority
    interrupt is asserted.

    Fix by sending the INTC an acknowledge if we find no interrupts to
    handle.

    Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20c2704142cdbaf4e55dd97af12ab59e5ead3462
Author: Brian Austin <brian.austin@cirrus.com>
Date:   Tue Mar 18 13:56:21 2014 -0500

    ASoC: cs42l73: Fix mask bits for SOC_VALUE_ENUM_SINGLE

    commit 1555b652970e541fa1cb80c61ffc696bbfb92bb7 upstream.

    The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the mono mix controls.

    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c10f1231aaf8f5f68d0870c2e9ea708a346c6ba
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Apr 26 17:13:46 2014 -0700

    Linux 3.4.88

commit 59760f50ff70b0eac8e91f15505e380ccede3287
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Apr 7 15:38:41 2014 -0700

    wait: fix reparent_leader() vs EXIT_DEAD->EXIT_ZOMBIE race

    commit dfccbb5e49a621c1b21a62527d61fc4305617aca upstream.

    wait_task_zombie() first does EXIT_ZOMBIE->EXIT_DEAD transition and
    drops tasklist_lock.  If this task is not the natural child and it is
    traced, we change its state back to EXIT_ZOMBIE for ->real_parent.

    The last transition is racy, this is even documented in 50b8d257486a
    "ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE
    race".  wait_consider_task() tries to detect this transition and clear
    ->notask_error but we can't rely on ptrace_reparented(), debugger can
    exit and do ptrace_unlink() before its sub-thread sets EXIT_ZOMBIE.

    And there is another problem which were missed before: this transition
    can also race with reparent_leader() which doesn't reset >exit_signal if
    EXIT_DEAD, assuming that this task must be reaped by someone else.  So
    the tracee can be re-parented with ->exit_signal != SIGCHLD, and if
    /sbin/init doesn't use __WALL it becomes unreapable.

    Change reparent_leader() to update ->exit_signal even if EXIT_DEAD.
    Note: this is the simple temporary hack for -stable, it doesn't try to
    solve all problems, it will be reverted by the next changes.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
    Reported-by: Michal Schmidt <mschmidt@redhat.com>
    Tested-by: Michal Schmidt <mschmidt@redhat.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Lennart Poettering <lpoetter@redhat.com>
    Cc: Roland McGrath <roland@hack.frob.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 852872eb2916203e00cbfe78e8409221c6234bcf
Author: Li Zefan <lizefan@huawei.com>
Date:   Wed Feb 12 12:44:57 2014 -0800

    jffs2: remove from wait queue after schedule()

    commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream.

    @wait is a local variable, so if we don't remove it from the wait queue
    list, later wake_up() may end up accessing invalid memory.

    This was spotted by eyes.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b5df201434b7c7ba418d84293d15eda2c15a3b7
Author: Li Zefan <lizefan@huawei.com>
Date:   Wed Feb 12 12:44:56 2014 -0800

    jffs2: avoid soft-lockup in jffs2_reserve_space_gc()

    commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.

    We triggered soft-lockup under stress test on 2.6.34 kernel.

    BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
    ...
    [<bf09a4d4>] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
    [<bf09a528>] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
    [<bf0a1350>] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
    [<bf0a2078>] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
    [<bf09a670>] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
    [<bf09dc48>] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
    [<bf097d8c>] (jffs2_write_end+0x198/0x2c0 [jffs2])
    [<c00e00a4>] (generic_file_buffered_write+0x158/0x200)
    [<c00e14f4>] (__generic_file_aio_write+0x3a4/0x414)
    [<c00e15c0>] (generic_file_aio_write+0x5c/0xbc)
    [<c012334c>] (do_sync_write+0x98/0xd4)
    [<c0123a84>] (vfs_write+0xa8/0x150)
    [<c0123d74>] (sys_write+0x3c/0xc0)]

    Fix this by adding a cond_resched() in the while loop.

    [akpm@linux-foundation.org: don't initialize `ret']
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4907bebb4fd2c2f8023dba01488a986f302aa6d2
Author: Ajesh Kunhipurayil Vijayan <ajesh@broadcom.com>
Date:   Mon Jan 6 19:06:55 2014 +0530

    jffs2: Fix crash due to truncation of csize

    commit 41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream.

    mounting JFFS2 partition sometimes crashes with this call trace:

    [ 1322.240000] Kernel bug detected[#1]:
    [ 1322.244000] Cpu 2
    [ 1322.244000] $ 0   : 0000000000000000 0000000000000018 000000003ff00070 0000000000000001
    [ 1322.252000] $ 4   : 0000000000000000 c0000000f3980150 0000000000000000 0000000000010000
    [ 1322.260000] $ 8   : ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8
    [ 1322.268000] $12   : e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e
    [ 1322.276000] $16   : c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000
    [ 1322.284000] $20   : c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0
    [ 1322.292000] $24   : 0000000000000004 0000000000000000
    [ 1322.300000] $28   : c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0
    [ 1322.308000] Hi    : 000000000000023c
    [ 1322.312000] Lo    : 000000000003f802
    [ 1322.316000] epc   : ffffffffc039a9f8 check_tn_node+0x88/0x3b0
    [ 1322.320000]     Not tainted
    [ 1322.324000] ra    : ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48
    [ 1322.332000] Status: 5400f8e3    KX SX UX KERNEL EXL IE
    [ 1322.336000] Cause : 00800034
    [ 1322.340000] PrId  : 000c1004 (Netlogic XLP)
    [ 1322.344000] Modules linked in:
    [ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c0000000ed2c0000, task=c0000000f0e68dd8, tls=0000000000000000)
    [ 1322.356000] Stack : c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000
            c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc
            c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000
            0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180
            0000008600000000 0000000000000000 0000000000000000 0000000000000000
            0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000
            0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00
            c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0
            0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90
            0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c
            ...
    [ 1322.424000] Call Trace:
    [ 1322.428000] [<ffffffffc039a9f8>] check_tn_node+0x88/0x3b0
    [ 1322.432000] [<ffffffffc039c0b0>] jffs2_do_read_inode_internal+0x1250/0x1e48
    [ 1322.440000] [<ffffffffc039cf90>] jffs2_do_crccheck_inode+0x70/0xd0
    [ 1322.448000] [<ffffffffc03a1b80>] jffs2_garbage_collect_pass+0x160/0x870
    [ 1322.452000] [<ffffffffc03a392c>] jffs2_garbage_collect_thread+0xdc/0x1f0
    [ 1322.460000] [<ffffffffc01541c8>] kthread+0xb8/0xc0
    [ 1322.464000] [<ffffffffc0106d18>] kernel_thread_helper+0x10/0x18
    [ 1322.472000]
    [ 1322.472000]
    Code: 67bd0050  94a4002c  2c830001 <00038036> de050218  2403fffc  0080a82d  00431824  24630044
    [ 1322.480000] ---[ end trace b052bb90e97dfbf5 ]---

    The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it
    is used to hold the compressed data length(csize) which is declared as uint32_t.
    So, when the value of csize exceeds 16bits, it gets truncated when assigned to
    tn->csize. This is causing a kernel BUG.
    Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue.

    Signed-off-by: Ajesh Kunhipurayil Vijayan <ajesh@broadcom.com>
    Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 161c6b2fe692f63755d95121a17efcd2be7f2799
Author: Kamlakant Patel <kamlakant.patel@broadcom.com>
Date:   Mon Jan 6 19:06:54 2014 +0530

    jffs2: Fix segmentation fault found in stress test

    commit 3367da5610c50e6b83f86d366d72b41b350b06a2 upstream.

    Creating a large file on a JFFS2 partition sometimes crashes with this call
    trace:

    [  306.476000] CPU 13 Unable to handle kernel paging request at virtual address c0000000dfff8002, epc == ffffffffc03a80a8, ra == ffffffffc03a8044
    [  306.488000] Oops[#1]:
    [  306.488000] Cpu 13
    [  306.492000] $ 0   : 0000000000000000 0000000000000000 0000000000008008 0000000000008007
    [  306.500000] $ 4   : c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58
    [  306.508000] $ 8   : 0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002
    [  306.516000] $12   : 0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb
    [  306.524000] $16   : c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70
    [  306.532000] $20   : ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000
    [  306.540000] $24   : 0000000000000000 0000000000000004
    [  306.548000] $28   : c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044
    [  306.556000] Hi    : 00000000000574a5
    [  306.560000] Lo    : 6193b7a7e903d8c9
    [  306.564000] epc   : ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198
    [  306.568000]     Tainted: G        W
    [  306.572000] ra    : ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198
    [  306.580000] Status: 5000f8e3    KX SX UX KERNEL EXL IE
    [  306.584000] Cause : 00800008
    [  306.588000] BadVA : c0000000dfff8002
    [  306.592000] PrId  : 000c1100 (Netlogic XLP)
    [  306.596000] Modules linked in:
    [  306.596000] Process dd (pid: 170, threadinfo=c0000000ee950000, task=c0000000ee6e0858, tls=0000000000c47490)
    [  306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f
            7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7
            7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb
            7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93
            7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64
            7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53
            7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80
            7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3
            7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6
            7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9
            ...
    [  306.676000] Call Trace:
    [  306.680000] [<ffffffffc03a80a8>] jffs2_rtime_compress+0x98/0x198
    [  306.684000] [<ffffffffc0394f10>] jffs2_selected_compress+0x110/0x230
    [  306.692000] [<ffffffffc039508c>] jffs2_compress+0x5c/0x388
    [  306.696000] [<ffffffffc039dc58>] jffs2_write_inode_range+0xd8/0x388
    [  306.704000] [<ffffffffc03971bc>] jffs2_write_end+0x16c/0x2d0
    [  306.708000] [<ffffffffc01d3d90>] generic_file_buffered_write+0xf8/0x2b8
    [  306.716000] [<ffffffffc01d4e7c>] __generic_file_aio_write+0x1ac/0x350
    [  306.720000] [<ffffffffc01d50a0>] generic_file_aio_write+0x80/0x168
    [  306.728000] [<ffffffffc021f7dc>] do_sync_write+0x94/0xf8
    [  306.732000] [<ffffffffc021ff6c>] vfs_write+0xa4/0x1a0
    [  306.736000] [<ffffffffc02202e8>] SyS_write+0x50/0x90
    [  306.744000] [<ffffffffc0116cc0>] handle_sys+0x180/0x1a0
    [  306.748000]
    [  306.748000]
    Code: 020b202d  0205282d  90a50000 <90840000> 14a40038  00000000  0060602d  0000282d  016c5823
    [  306.760000] ---[ end trace 79dd088435be02d0 ]---
    Segmentation fault

    This crash is caused because the 'positions' is declared as an array of signed
    short. The value of position is in the range 0..65535, and will be converted
    to a negative number when the position is greater than 32767 and causes a
    corruption and crash. Changing the definition to 'unsigned short' fixes this
    issue

    Signed-off-by: Jayachandran C <jchandra@broadcom.com>
    Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85f452437cc7f080e5c98908d8b65ce8e9937bc5
Author: Claudio Takahasi <claudio.takahasi@openbossa.org>
Date:   Thu Jul 25 16:34:24 2013 -0300

    Bluetooth: Fix removing Long Term Key

    commit 5981a8821b774ada0be512fd9bad7c241e17657e upstream.

    This patch fixes authentication failure on LE link re-connection when
    BlueZ acts as slave (peripheral). LTK is removed from the internal list
    after its first use causing PIN or Key missing reply when re-connecting
    the link. The LE Long Term Key Request event indicates that the master
    is attempting to encrypt or re-encrypt the link.

    Pre-condition: BlueZ host paired and running as slave.
    How to reproduce(master):

      1) Establish an ACL LE encrypted link
      2) Disconnect the link
      3) Try to re-establish the ACL LE encrypted link (fails)

    > HCI Event: LE Meta Event (0x3e) plen 19
          LE Connection Complete (0x01)
            Status: Success (0x00)
            Handle: 64
            Role: Slave (0x01)
    ...
    @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
    > HCI Event: LE Meta Event (0x3e) plen 13
          LE Long Term Key Request (0x05)
            Handle: 64
            Random number: 875be18439d9aa37
            Encryption diversifier: 0x76ed
    < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
            Handle: 64
            Long term key: 2aa531db2fce9f00a0569c7d23d17409
    > HCI Event: Command Complete (0x0e) plen 6
          LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
            Status: Success (0x00)
            Handle: 64
    > HCI Event: Encryption Change (0x08) plen 4
            Status: Success (0x00)
            Handle: 64
            Encryption: Enabled with AES-CCM (0x01)
    ...
    @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3
    < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
            Advertising: Enabled (0x01)
    > HCI Event: Command Complete (0x0e) plen 4
          LE Set Advertise Enable (0x08|0x000a) ncmd 1
            Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 19
          LE Connection Complete (0x01)
            Status: Success (0x00)
            Handle: 64
            Role: Slave (0x01)
    ...
    @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
    > HCI Event: LE Meta Event (0x3e) plen 13
          LE Long Term Key Request (0x05)
            Handle: 64
            Random number: 875be18439d9aa37
            Encryption diversifier: 0x76ed
    < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2
            Handle: 64
    > HCI Event: Command Complete (0x0e) plen 6
          LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1
            Status: Success (0x00)
            Handle: 64
    > HCI Event: Disconnect Complete (0x05) plen 4
            Status: Success (0x00)
            Handle: 64
            Reason: Authentication Failure (0x05)
    @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0

    Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d1b55f70df471d11c8aca64add6f028a16ce2c4
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Apr 14 09:46:50 2014 -0500

    Char: ipmi_bt_sm, fix infinite loop

    commit a94cdd1f4d30f12904ab528152731fb13a812a16 upstream.

    In read_all_bytes, we do

      unsigned char i;
      ...
      bt->read_data[0] = BMC2HOST;
      bt->read_count = bt->read_data[0];
      ...
      for (i = 1; i <= bt->read_count; i++)
        bt->read_data[i] = BMC2HOST;

    If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
    'for' loop.  Make 'i' an 'int' instead of 'char' to get rid of the
    overflow and finish the loop after 255 iterations every time.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Reported-and-debugged-by: Rui Hui Dian <rhdian@novell.com>
    Cc: Tomas Cech <tcech@suse.cz>
    Cc: Corey Minyard <minyard@acm.org>
    Cc: <openipmi-developer@lists.sourceforge.net>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a85757b9fba70107fd50a0f693481fdbfd48a2a
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Fri Mar 14 10:42:01 2014 -0500

    sparc64: don't treat 64-bit syscall return codes as 32-bit

    [ Upstream commit 1535bd8adbdedd60a0ee62e28fd5225d66434371 ]

    When checking a system call return code for an error,
    linux_sparc_syscall was sign-extending the lower 32-bit value and
    comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return
    codes whose lower 32-bits alone would indicate a failure (such as 4G-1).
    Use the whole 64-bit value to check for errors. Only the 32-bit path
    should sign extend the lower 32-bit value.

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Acked-by: Bob Picco <bob.picco@oracle.com>
    Acked-by: Allen Pais <allen.pais@oracle.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b288a34b804fed64522c56f6e4bb7cdfdcb0b35
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Thu Feb 13 13:57:44 2014 -0500

    sparc32: fix build failure for arch_jump_label_transform

    [ Upstream commit 4f6500fff5f7644a03c46728fd7ef0f62fa6940b ]

    In arch/sparc/Kernel/Makefile, we see:

       obj-$(CONFIG_SPARC64)   += jump_label.o

    However, the Kconfig selects HAVE_ARCH_JUMP_LABEL unconditionally
    for all SPARC.  This in turn leads to the following failure when
    doing allmodconfig coverage builds:

    kernel/built-in.o: In function `__jump_label_update':
    jump_label.c:(.text+0x8560c): undefined reference to `arch_jump_label_transform'
    kernel/built-in.o: In function `arch_jump_label_transform_static':
    (.text+0x85cf4): undefined reference to `arch_jump_label_transform'
    make: *** [vmlinux] Error 1

    Change HAVE_ARCH_JUMP_LABEL to be conditional on SPARC64 so that it
    matches the Makefile.

    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8569901f8a6b77696a947c7c1e7cf68fe55f11b
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Mon Dec 16 15:01:00 2013 -0600

    Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."

    [ Upstream commit 16932237f2978a2265662f8de4af743b1f55a209 ]

    This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2.

    This commit broke the behavior of __copy_from_user_inatomic when
    it is only partially successful. Instead of returning the number
    of bytes not copied, it now returns 1. This translates to the
    wrong value being returned by iov_iter_copy_from_user_atomic.

    xfstests generic/246 and LTP writev01 both fail on btrfs and nfs
    because of this.

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dffdaee9e236b4828749c81f29493d2e4d034e5
Author: oftedal <oftedal@gmail.com>
Date:   Fri Oct 18 22:28:29 2013 +0200

    sparc: PCI: Fix incorrect address calculation of PCI Bridge windows on Simba-bridges

    [ Upstream commit 557fc5873ef178c4b3e1e36a42db547ecdc43f9b ]

    The SIMBA APB Bridges lacks the 'ranges' of-property describing the
    PCI I/O and memory areas located beneath the bridge. Faking this
    information has been performed by reading range registers in the
    APB bridge, and calculating the corresponding areas.

    In commit 01f94c4a6ced476ce69b895426fc29bfc48c69bd
    ("Fix sabre pci controllers with new probing scheme.") a bug was
    introduced into this calculation, causing the PCI memory areas
    to be calculated incorrectly: The shift size was set to be
    identical for I/O and MEM ranges, which is incorrect.

    This patch set the shift size of the MEM range back to the
    value used before 01f94c4a6ced476ce69b895426fc29bfc48c69bd.

    Signed-off-by: Kjetil Oftedal <oftedal@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 612be517bf7d45f1c8b44e17c5310774688b6f83
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Sat Mar 29 20:39:35 2014 -0400

    rds: prevent dereference of a NULL device in rds_iw_laddr_check

    [ Upstream commit bf39b4247b8799935ea91d90db250ab608a58e50 ]

    Binding might result in a NULL device which is later dereferenced
    without checking.

    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18ed5d68d9e28e93c55d665008702e5c733bc265
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Apr 8 12:23:09 2014 +0300

    isdnloop: several buffer overflows

    [ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ]

    There are three buffer overflows addressed in this patch.

    1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
    then copy it into a 60 character buffer.  I have made the destination
    buffer 64 characters and I'm changed the sprintf() to a snprintf().

    2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
    character buffer so we have 54 characters.  The ->eazlist[] is 11
    characters long.  I have modified the code to return if the source
    buffer is too long.

    3) In isdnloop_command() the cbuf[] array was 60 characters long but the
    max length of the string then can be up to 79 characters.  I made the
    cbuf array 80 characters long and changed the sprintf() to snprintf().
    I also removed the temporary "dial" buffer and changed it to use "p"
    directly.

    Unfortunately, we pass the "cbuf" string from isdnloop_command() to
    isdnloop_writecmd() which truncates anything over 60 characters to make
    it fit in card->omsg[].  (It can accept values up to 255 characters so
    long as there is a '\n' character every 60 characters).  For now I have
    just fixed the memory corruption bug and left the other problems in this
    driver alone.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46a30152e06599613755ed87b07ba86425b48875
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date:   Wed Apr 2 12:48:42 2014 +0900

    isdnloop: Validate NUL-terminated strings from user.

    [ Upstream commit 77bc6bed7121936bb2e019a8c336075f4c8eef62 ]

    Return -EINVAL unless all of user-given strings are correctly
    NUL-terminated.

    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26f266047bdfeb56469abb9180930d7fb9fea9fe
Author: Pablo Neira <pablo@netfilter.org>
Date:   Tue Apr 1 19:38:44 2014 +0200

    netlink: don't compare the nul-termination in nla_strcmp

    [ Upstream commit 8b7b932434f5eee495b91a2804f5b64ebb2bc835 ]

    nla_strcmp compares the string length plus one, so it's implicitly
    including the nul-termination in the comparison.

     int nla_strcmp(const struct nlattr *nla, const char *str)
     {
            int len = strlen(str) + 1;
            ...
                    d = memcmp(nla_data(nla), str, len);

    However, if NLA_STRING is used, userspace can send us a string without
    the nul-termination. This is a problem since the string
    comparison will not match as the last byte may be not the
    nul-termination.

    Fix this by skipping the comparison of the nul-termination if the
    attribute data is nul-terminated. Suggested by Thomas Graf.

    Cc: Florian Westphal <fw@strlen.de>
    Cc: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c16e2397790c5c908fefcbbed080429b682a1ffc
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Mon Mar 31 20:14:10 2014 +0200

    ipv6: some ipv6 statistic counters failed to disable bh

    [ Upstream commit 43a43b6040165f7b40b5b489fe61a4cb7f8c4980 ]

    After commit c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify
    processing to workqueue") some counters are now updated in process context
    and thus need to disable bh before doing so, otherwise deadlocks can
    happen on 32-bit archs. Fabio Estevam noticed this while while mounting
    a NFS volume on an ARM board.

    As a compensation for missing this I looked after the other *_STATS_BH
    and found three other calls which need updating:

    1) icmp6_send: ip6_fragment -> icmpv6_send -> icmp6_send (error handling)
    2) ip6_push_pending_frames: rawv6_sendmsg -> rawv6_push_pending_frames -> ...
       (only in case of icmp protocol with raw sockets in error handling)
    3) ping6_v6_sendmsg (error handling)

    Fixes: c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify processing to workqueue")
    Reported-by: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b83cbca47548cd454dad9be4dc93c09b849e1755
Author: Paul Durrant <Paul.Durrant@citrix.com>
Date:   Fri Mar 28 11:39:05 2014 +0000

    xen-netback: remove pointless clause from if statement

    [ Upstream commit 0576eddf24df716d8570ef8ca11452a9f98eaab2 ]

    This patch removes a test in start_new_rx_buffer() that checks whether
    a copy operation is less than MAX_BUFFER_OFFSET in length, since
    MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of
    start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less.

    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: Wei Liu <wei.liu2@citrix.com>
    Cc: Sander Eikelenboom <linux@eikelenboom.it>
    Reported-By: Sander Eikelenboom <linux@eikelenboom.it>
    Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb338d57c4690c776f49c248d273946f2e81804c
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Mar 27 12:53:37 2014 +0200

    vhost: validate vhost_get_vq_desc return value

    [ Upstream commit a39ee449f96a2cd44ce056d8a0a112211a9b1a1f ]

    vhost fails to validate negative error code
    from vhost_get_vq_desc causing
    a crash: we are using -EFAULT which is 0xfffffff2
    as vector size, which exceeds the allocated size.

    The code in question was introduced in commit
    8dd014adfea6f173c1ef6378f7e5e7924866c923
        vhost-net: mergeable buffers support

    CVE-2014-0055

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

commit 9329d8ee423dd8dcd21f8ba582606ca5bd65c885
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Mar 27 12:00:26 2014 +0200

    vhost: fix total length when packets are too short

    [ Upstream commit d8316f3991d207fe32881a9ac20241be8fa2bad0 ]

    When mergeable buffers are disabled, and the
    incoming packet is too large for the rx buffer,
    get_rx_bufs returns success.

    This was intentional in order for make recvmsg
    truncate the packet and then handle_rx would
    detect err != sock_len and drop it.

    Unfortunately we pass the original sock_len to
    recvmsg - which means we use parts of iov not fully
    validated.

    Fix this up by detecting this overrun and doing packet drop
    immediately.

    CVE-2014-0077

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

commit f085942592db7e10a16a0426226988909bfd28a0
Author: lucien <lucien.xin@gmail.com>
Date:   Mon Mar 17 12:51:01 2014 +0800

    ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly

    [ Upstream commit e367c2d03dba4c9bcafad24688fadb79dd95b218 ]

    In ip6_append_data_mtu(), when the xfrm mode is not tunnel(such as
    transport),the ipsec header need to be added in the first fragment, so the mtu
    will decrease to reserve space for it, then the second fragment come, the mtu
    should be turn back, as the commit 0c1833797a5a6ec23ea9261d979aa18078720b74
    said.  however, in the commit a493e60ac4bbe2e977e7129d6d8cbb0dd236be, it use
    *mtu = min(*mtu, ...) to change the mtu, which lead to the new mtu is alway
    equal with the first fragment's. and cannot turn back.

    when I test through  ping6 -c1 -s5000 $ip (mtu=1280):
    ...frag (0|1232) ESP(spi=0x00002000,seq=0xb), length 1232
    ...frag (1232|1216)
    ...frag (2448|1216)
    ...frag (3664|1216)
    ...frag (4880|164)

    which should be:
    ...frag (0|1232) ESP(spi=0x00001000,seq=0x1), length 1232
    ...frag (1232|1232)
    ...frag (2464|1232)
    ...frag (3696|1232)
    ...frag (4928|116)

    so delete the min() when change back the mtu.

    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Fixes: 75a493e60ac4bb ("ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size")
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dfbd2cbdf9d60f8595840ab452f9264347469de
Author: Heiner Kallweit <heiner.kallweit@web.de>
Date:   Wed Mar 12 22:13:19 2014 +0100

    ipv6: Avoid unnecessary temporary addresses being generated

    [ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]

    tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
    age needs to be added to the condition.

    Age calculation in ipv6_create_tempaddr is different from the one
    in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
    This can cause age in ipv6_create_tempaddr to be less than the one
    in addrconf_verify and therefore unnecessary temporary address to
    be generated.
    Use age calculation as in addrconf_modify to avoid this.

    Signed-off-by: Heiner Kallweit <heiner.kallweit@web.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6e6117f122d7f27361147b977b38f7a224a32aa
Author: Matthew Leach <matthew.leach@arm.com>
Date:   Tue Mar 11 11:58:27 2014 +0000

    net: socket: error on a negative msg_namelen

    [ Upstream commit dbb490b96584d4e958533fb637f08b557f505657 ]

    When copying in a struct msghdr from the user, if the user has set the
    msg_namelen parameter to a negative value it gets clamped to a valid
    size due to a comparison between signed and unsigned values.

    Ensure the syscall errors when the user passes in a negative value.

    Signed-off-by: Matthew Leach <matthew.leach@arm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 135fb5c2722c2ee8a729faa56b0595b0d4dca06a
Author: Peter Boström <peter.bostrom@netrounds.com>
Date:   Mon Mar 10 16:17:15 2014 +0100

    vlan: Set correct source MAC address with TX VLAN offload enabled

    [ Upstream commit dd38743b4cc2f86be250eaf156cf113ba3dd531a ]

    With TX VLAN offload enabled the source MAC address for frames sent using the
    VLAN interface is currently set to the address of the real interface. This is
    wrong since the VLAN interface may be configured with a different address.

    The bug was introduced in commit 2205369a314e12fcec4781cc73ac9c08fc2b47de
    ("vlan: Fix header ops passthru when doing TX VLAN offload.").

    This patch sets the source address before calling the create function of the
    real interface.

    Signed-off-by: Peter Boström <peter.bostrom@netrounds.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d68a3cd4fa01725efd020cfc0b818438ece9b0b3
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Mar 6 17:51:57 2014 +0100

    ipv6: don't set DST_NOCOUNT for remotely added routes

    [ Upstream commit c88507fbad8055297c1d1e21e599f46960cbee39 ]

    DST_NOCOUNT should only be used if an authorized user adds routes
    locally. In case of routes which are added on behalf of router
    advertisments this flag must not get used as it allows an unlimited
    number of routes getting added remotely.

    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed9f5f2bd084d43f16672da20ff16f59ecdb9334
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 25 18:42:27 2014 -0700

    net: unix: non blocking recvmsg() should not return -EINTR

    [ Upstream commit de1443916791d75fdd26becb116898277bb0273f ]

    Some applications didn't expect recvmsg() on a non blocking socket
    could return -EINTR. This possibility was added as a side effect
    of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
    unix recv routines").

    To hit this bug, you need to be a bit unlucky, as the u->readlock
    mutex is usually held for very small periods.

    Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efd7c757472c4dcebc44500ccb440bd583e63f33
Author: Linus Lüssing <linus.luessing@web.de>
Date:   Tue Mar 4 03:57:35 2014 +0100

    bridge: multicast: add sanity check for query source addresses

    [ Upstream commit 6565b9eeef194afbb3beec80d6dd2447f4091f8c ]

    MLD queries are supposed to have an IPv6 link-local source address
    according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
    adds a sanity check to ignore such broken MLD queries.

    Without this check, such malformed MLD queries can result in a
    denial of service: The queries are ignored by any MLD listener
    therefore they will not respond with an MLD report. However,
    without this patch these malformed MLD queries would enable the
    snooping part in the bridge code, potentially shutting down the
    according ports towards these hosts for multicast traffic as the
    bridge did not learn about these listeners.

    Reported-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Linus Lüssing <linus.luessing@web.de>
    Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 871cb0f8d86f151f8e38ed87920a15291bcf02c3
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Tue Mar 4 16:35:51 2014 +0100

    net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk

    [ Upstream commit c485658bae87faccd7aed540fd2ca3ab37992310 ]

    While working on ec0223ec48a9 ("net: sctp: fix sctp_sf_do_5_1D_ce to
    verify if we/peer is AUTH capable"), we noticed that there's a skb
    memory leakage in the error path.

    Running the same reproducer as in ec0223ec48a9 and by unconditionally
    jumping to the error label (to simulate an error condition) in
    sctp_sf_do_5_1D_ce() receive path lets kmemleak detector bark about
    the unfreed chunk->auth_chunk skb clone:

    Unreferenced object 0xffff8800b8f3a000 (size 256):
      comm "softirq", pid 0, jiffies 4294769856 (age 110.757s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        89 ab 75 5e d4 01 58 13 00 00 00 00 00 00 00 00  ..u^..X.........
      backtrace:
        [<ffffffff816660be>] kmemleak_alloc+0x4e/0xb0
        [<ffffffff8119f328>] kmem_cache_alloc+0xc8/0x210
        [<ffffffff81566929>] skb_clone+0x49/0xb0
        [<ffffffffa0467459>] sctp_endpoint_bh_rcv+0x1d9/0x230 [sctp]
        [<ffffffffa046fdbc>] sctp_inq_push+0x4c/0x70 [sctp]
        [<ffffffffa047e8de>] sctp_rcv+0x82e/0x9a0 [sctp]
        [<ffffffff815abd38>] ip_local_deliver_finish+0xa8/0x210
        [<ffffffff815a64af>] nf_reinject+0xbf/0x180
        [<ffffffffa04b4762>] nfqnl_recv_verdict+0x1d2/0x2b0 [nfnetlink_queue]
        [<ffffffffa04aa40b>] nfnetlink_rcv_msg+0x14b/0x250 [nfnetlink]
        [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
        [<ffffffffa04aa7cf>] nfnetlink_rcv+0x23f/0x408 [nfnetlink]
        [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
        [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
        [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
        [<ffffffff8155d449>] ___sys_sendmsg+0x369/0x380

    What happens is that commit bbd0d59809f9 clones the skb containing
    the AUTH chunk in sctp_endpoint_bh_rcv() when having the edge case
    that 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 ---------------------

    When we enter sctp_sf_do_5_1D_ce() and before we actually get to
    the point where we process (and subsequently free) a non-NULL
    chunk->auth_chunk, we could hit the "goto nomem_init" path from
    an error condition and thus leave the cloned skb around w/o
    freeing it.

    The fix is to centrally free such clones in sctp_chunk_destroy()
    handler that is invoked from sctp_chunk_free() after all refs have
    dropped; and also move both kfree_skb(chunk->auth_chunk) there,
    so that chunk->auth_chunk is either NULL (since sctp_chunkify()
    allocs new chunks through kmem_cache_zalloc()) or non-NULL with
    a valid skb pointer. chunk->skb and chunk->auth_chunk are the
    only skbs in the sctp_chunk structure that need to be handeled.

    While at it, we should use consume_skb() for both. It is the same
    as dev_kfree_skb() but more appropriately named as we are not
    a device but a protocol. Also, this effectively replaces the
    kfree_skb() from both invocations into consume_skb(). Functions
    are the same only that kfree_skb() assumes that the frame was
    being dropped after a failure (e.g. for tools like drop monitor),
    usage of consume_skb() seems more appropriate in function
    sctp_chunk_destroy() though.

    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>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39dbb037651b4c48ea297f7ee11e65eb166e5112
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Apr 14 06:45:17 2014 -0700

    Linux 3.4.87

commit 1e49dae8016ee875a70c62dad310a493dbd45996
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Dec 11 19:39:19 2013 -0500

    powernow-k6: reorder frequencies

    commit 22c73795b101597051924556dce019385a1e2fa0 upstream.

    This patch reorders reported frequencies from the highest to the lowest,
    just like in other frequency drivers.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96e21a371386821f91363434ee1a0f1cda5db990
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Dec 11 19:38:53 2013 -0500

    powernow-k6: correctly initialize default parameters

    commit d82b922a4acc1781d368aceac2f9da43b038cab2 upstream.

    The powernow-k6 driver used to read the initial multiplier from the
    powernow register. However, there is a problem with this:

    * If there was a frequency transition before, the multiplier read from the
      register corresponds to the current multiplier.
    * If there was no frequency transition since reset, the field in the
      register always reads as zero, regardless of the current multiplier that
      is set using switches on the mainboard and that the CPU is running at.

    The zero value corresponds to multiplier 4.5, so as a consequence, the
    powernow-k6 driver always assumes multiplier 4.5.

    For example, if we have 550MHz CPU with bus frequency 100MHz and
    multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5
    and bus frequency is 122MHz. The powernow-k6 driver then sets the
    multiplier to 4.5, underclocking the CPU to 450MHz, but reports the
    current frequency as 550MHz.

    There is no reliable way how to read the initial multiplier. I modified
    the driver so that it contains a table of known frequencies (based on
    parameters of existing CPUs and some common overclocking schemes) and sets
    the multiplier according to the frequency. If the frequency is unknown
    (because of unusual overclocking or underclocking), the user must supply
    the bus speed and maximum multiplier as module parameters.

    This patch should be backported to all stable kernels. If it doesn't
    apply cleanly, change it, or ask me to change it.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07fe6099fb0ae32de56aa49804d71050fa5a7327
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Dec 11 19:38:32 2013 -0500

    powernow-k6: disable cache when changing frequency

    commit e20e1d0ac02308e2211306fc67abcd0b2668fb8b upstream.

    I found out that a system with k6-3+ processor is unstable during network
    server load. The system locks up or the network card stops receiving. The
    reason for the instability is the CPU frequency scaling.

    During frequency transition the processor is in "EPM Stop Grant" state.
    The documentation says that the processor doesn't respond to inquiry
    requests in this state. Consequently, coherency of processor caches and
    bus master devices is not maintained, causing the system instability.

    This patch flushes the cache during frequency transition. It fixes the
    instability.

    Other minor changes:
    * u64 invalue changed to unsigned long because the variable is 32-bit
    * move the logic to set the multiplier to a separate function
      powernow_k6_set_cpu_multiplier
    * preserve lower 5 bits of the powernow port instead of 4 (the voltage
      field has 5 bits)
    * mask interrupts when reading the multiplier, so that the port is not
      open during other activity (running other kernel code with the port open
      shouldn't cause any misbehavior, but we should better be safe and keep
      the port closed)

    This patch should be backported to all stable kernels. If it doesn't
    apply cleanly, change it, or ask me to change it.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7c16f1a5cc6544923b55795ed60d49946c5e2c6
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Oct 25 06:34:03 2013 -0300

    media: saa7164: fix return value check in saa7164_initdev()

    commit 89f4d45b2752df5d222b5f63919ce59e2d8afaf4 upstream.

    In case of error, the function kthread_run() returns ERR_PTR()
    and never returns NULL. The NULL test in the return value check
    should be replaced with IS_ERR().

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a91e3c8ce762879f0c0ac4ab3d81a62658ff8a36
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Jul 3 16:17:34 2013 -0300

    media: hdpvr: fix iteration over uninitialized lists in hdpvr_probe()

    commit 2e923a0527ac439e135b9961e58d3acd876bba10 upstream.

    free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
    but if something bad happens before that, error handling code calls hdpvr_delete(),
    which contains iteration over the lists (via hdpvr_free_buffers()).
    The patch moves the lists initialization to the beginning and by the way fixes
    goto label in error handling of registering videodev.
    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4b90c5d2ed3b4dccfad9583e7f3c6cfddec9c10
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Mar 19 09:34:58 2013 -0300

    media: hdpvr: register the video node at the end of probe

    commit 280847b532433ffe7a22795f926327805a127162 upstream.

    Video nodes can be used at once after registration, so make sure the full
    initialization is done before registering them.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ee87fcc047798753b17110305c90260a180c7c3
Author: Soeren Moch <smoch@web.de>
Date:   Wed Jun 5 21:26:23 2013 -0300

    media: dmxdev: remove dvb_ringbuffer_flush() on writer side

    commit 414abbd2cd4c2618895f02ed3a76ec6647281436 upstream.

    In dvb_ringbuffer lock-less synchronizationof reader and writer threads is done
    with separateread and write pointers. Sincedvb_ringbuffer_flush() modifies the
    read pointer, this function must not be called from the writer thread.
    This patch removes the dvb_ringbuffer_flush() calls in the dmxdev ringbuffer
    write functions, this fixes Oopses "Unable to handle kernel paging request"
    I could observe for the call chaindvb_demux_read ->dvb_dmxdev_buffer_read ->
    dvb_ringbuffer_read_user -> __copy_to_user (the reader side of the ringbuffer).
    The flush calls at the write side are not necessary anyway since ringbuffer_flush
    is also called in dvb_dmxdev_buffer_read() when an error condition is set in the
    ringbuffer.
    This patch should also be applied to stable kernels.

    Signed-off-by: Soeren Moch <smoch@web.de>
    Reviewed-by: Sakari Ailus <sakari.ailus@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60a89e4b5b6ff869983ba9a87377501668136618
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Sun Dec 16 16:04:46 2012 -0300

    media: omap_vout: find_vma() needs ->mmap_sem held

    commit 55ee64b30a38d688232e5eb2860467dddc493573 upstream.

    Walking rbtree while it's modified is a Bad Idea(tm); besides,
    the result of find_vma() can be freed just as it's getting returned
    to caller.  Fortunately, it's easy to fix - just take ->mmap_sem a bit
    earlier (and don't bother with find_vma() at all if virtp >= PAGE_OFFSET -
    in that case we don't even look at its result).

    While we are at it, what prevents VIDIOC_PREPARE_BUF calling
    v4l_prepare_buf() -> (e.g) vb2_ioctl_prepare_buf() -> vb2_prepare_buf() ->
    __buf_prepare() -> __qbuf_userptr() -> vb2_vmalloc_get_userptr() -> find_vma(),
    AFAICS without having taken ->mmap_sem anywhere in process?  The code flow
    is bloody convoluted and depends on a bunch of things done by initialization,
    so I certainly might've missed something...

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Sakari Ailus <sakari.ailus@iki.fi>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Archit Taneja <archit@ti.com>
    Cc: Prabhakar Lad <prabhakar.lad@ti.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7cbde819b03e8202a47991543dc98e78e0a64e6
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Sat Nov 24 21:35:48 2012 -0300

    media: v4l: Reset subdev v4l2_dev field to NULL if registration fails

    commit 317efce991620adc589b3005b9baed433dcb2a56 upstream.

    When subdev registration fails the subdev v4l2_dev field is left to a
    non-NULL value. Later calls to v4l2_device_unregister_subdev() will
    consider the subdev as registered and will module_put() the subdev
    module without any matching module_get().
    Fix this by setting the subdev v4l2_dev field to NULL in
    v4l2_device_register_subdev() when the function fails.

    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust context, filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85e28206469a76326fe9e774c1a546b97b9bd153
Author: Jacob Schloss <jacob.schloss@unlimitedautomata.com>
Date:   Sun Dec 9 20:18:25 2012 -0300

    media: gspca_kinect: add Kinect for Windows USB id

    commit 98fd485795db064d0885150e2c0c7f296d8fe06e upstream.

    Add the USB ID for the Kinect for Windows RGB camera so it can be used
    with the gspca_kinect driver.

    Signed-off-by: Jacob Schloss <jacob.schloss@unlimitedautomata.com>
    Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d546a77fa26fdf7c9c5e73dd1cf9d739ab2ea3f8
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Mon Jun 3 09:19:34 2013 +0000

    tg3: Add read dma workaround for 5720

    commit 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8 upstream.

    Commit 091f0ea30074bc43f9250961b3247af713024bc6 "tg3: Add New 5719 Read
    DMA workaround" added a workaround for TX DMA stall on the 5719. This
    workaround needs to be applied to the 5720 as well.

    Reported-by: Roland Dreier <roland@purestorage.com>
    Tested-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: use GET_ASIC_REV() instead of tg3_asic_rev()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backproted to 3.4: Adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7584e5bb4b4d696f1ef1f9a943edb57c8145f6cf
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Mon May 13 11:04:15 2013 +0000

    tg3: Skip powering down function 0 on certain serdes devices

    commit 44f3b503c16425c8e9db4bbaa2fc9cd0c9d0ba91 upstream.

    On the 5718, 5719 and 5720 serdes devices, powering down function 0
    results in all the other ports being powered down. Add code to skip
    function 0 power down.

    v2:
     - Modify tg3_phy_power_bug() function to use a switch instead of a
       complicated if statement. Suggested by Joe Perches.

    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>
    [bwh: Backported to 3.2:
     s/tg3_asic_rev\(tp\)/GET_ASIC_REV(tp->pci_chip_rev_id)/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backported to 3.4: Adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5e6b3e240149a10dec6761646268c92c3774dc9
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Thu Sep 20 12:09:30 2012 -0300

    sb_edac: Avoid overflow errors at memory size calculation

    commit deb09ddaff1435f72dd598d38f9b58354c68a5ec upstream.

    Sandy bridge EDAC is calculating the memory size with overflow.
    Basically, the size field and the integer calculation is using 32 bits.
    More bits are needed, when the DIMM memories have high density.

    The net result is that memories are improperly reported there, when
    high-density DIMMs are used:

    EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 0, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
    EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 1, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800

    As the number of pages value is handled at the EDAC core as unsigned
    ints, the driver shows the 16 GB memories at sysfs interface as 16760832
    MB! The fix is simple: calculate the number of pages as unsigned 64-bits
    integer.

    After the patch, the memory size (16 GB) is properly detected:

    EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 0, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
    EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 1, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800

    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Debug log function is debugf0(), not edac_dbg()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a9b7154c55fe8c7c23900b9f23166561c1d4745
Author: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Date:   Tue Jul 17 17:16:10 2012 +0300

    mmc: mxs-mmc: fix deadlock caused by recursion loop

    commit fc108d24d3a6da63576a460e122fa1df0cbdea20 upstream.

    Release the lock before mmc_signal_sdio_irq is called by
    mxs_mmc_enable_sdio_irq.

    Backtrace:
    [   65.470000] =============================================
    [   65.470000] [ INFO: possible recursive locking detected ]
    [   65.470000] 3.5.0-rc5 #2 Not tainted
    [   65.470000] ---------------------------------------------
    [   65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
    [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] but task is already holding lock:
    [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] other info that might help us debug this:
    [   65.470000]  Possible unsafe locking scenario:
    [   65.470000]
    [   65.470000]        CPU0
    [   65.470000]        ----
    [   65.470000]   lock(&(&host->lock)->rlock#2);
    [   65.470000]   lock(&(&host->lock)->rlock#2);
    [   65.470000]
    [   65.470000]  *** DEADLOCK ***
    [   65.470000]
    [   65.470000]  May be due to missing lock nesting notation
    [   65.470000]
    [   65.470000] 1 lock held by ksdioirqd/mmc0/73:
    [   65.470000]  #0:  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] stack backtrace:
    [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
    [   65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
    [   65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
    [   65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
    [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
    [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
    [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
    [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
    [   65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
    [   65.470000]  lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
    [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
    [   65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
    [   65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
    [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
    [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
    [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
    [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)

    Reported-by: Attila Kinali <attila@kinali.ch>
    Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - HW_SSP_STATUS is a simple rather than function-like macro]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3e75fd64eb43828181c60ccc82121bdac2d09bd
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Tue Aug 21 09:09:48 2012 +0300

    OMAPFB: fix framebuffer console colors

    commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.

    omapfb does not currently set pseudo palette correctly for color depths
    above 16bpp, making red text invisible, command like
      echo -e '\e[0;31mRED' > /dev/tty1
    will display nothing on framebuffer console in 24bpp mode.
    This is because temporary variable is declared incorrectly, fix it.

    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2a383402290359e6466a94f6eea82ab53e75c10
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Wed Jun 12 11:08:59 2013 -0700

    tg3: Wait for boot code to finish after power on

    commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream.

    Some systems that don't need wake-on-lan may choose to power down the
    chip on system standby. Upon resume, the power on causes the boot code
    to startup and initialize the hardware. On one new platform, this is
    causing the device to go into a bad state due to a race between the
    driver and boot code, once every several hundred resumes. The same race
    exists on open since we come up from a power on.

    This patch adds a wait for boot code signature at the beginning of
    tg3_init_hw() which is common to both cases. If there has not been a
    power-off or the boot code has already completed, the signature will be
    present and poll_fw() returns immediately. Also return immediately if
    the device does not have firmware.

    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f3b9f51984ed7174bdc7d9bc16de4fe2a854a55
Author: Michael Chan <mchan@broadcom.com>
Date:   Sun Jul 29 19:15:43 2012 +0000

    tg3: Add New 5719 Read DMA workaround

    commit 091f0ea30074bc43f9250961b3247af713024bc6 upstream.

    After Power-on-reset, the 5719's TX DMA length registers may contain
    uninitialized values and cause TX DMA to stall.  Check for invalid
    values and set a register bit to flush the TX channels.  The bit
    needs to be turned off after the DMA channels have been flushed.

    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 132d2672dc43f56387b0b5ccd173d9870a898ac3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 12 08:05:33 2013 +0100

    hwmon: Prevent some divide by zeros in FAN_TO_REG()

    commit 3806b45ba4655147a011df03242cc197ab986c43 upstream.

    The "rpm * div" operations can overflow here, so this patch adds an
    upper limit to rpm to prevent that.  Jean Delvare helped me with this
    patch.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Roger Lucas <vt8231@hiddenengine.co.uk>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf76bd5712d43d7af4d3ead64b3e14d7c8d25d39
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Wed Oct 2 19:15:03 2013 +0200

    hwmon: (applesmc) Always read until end of data

    commit 25f2bd7f5add608c1d1405938f39c96927b275ca upstream.

    The crash reported and investigated in commit 5f4513 turned out to be
    caused by a change to the read interface on newer (2012) SMCs.

    Tests by Chris show that simply reading the data valid line is enough
    for the problem to go away. Additional tests show that the newer SMCs
    no longer wait for the number of requested bytes, but start sending
    data right away.  Apparently the number of bytes to read is no longer
    specified as before, but instead found out by reading until end of
    data. Failure to read until end of data confuses the state machine,
    which eventually causes the crash.

    As a remedy, assuming bit0 is the read valid line, make sure there is
    nothing more to read before leaving the read function.

    Tested to resolve the original problem, and runtested on MBA3,1,
    MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
    machines before 2012.

    Tested-by: Chris Murphy <chris@cmurf.com>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6efbc17a56ecb574a5d093dfd80dcb04ddd6f63c
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Oct 9 13:23:57 2012 -0700

    hwmon: (coretemp) Add support for Atom CE4110/4150/4170

    commit 1102dcab849313bd5a340b299b5cf61b518fbc0f upstream.

    TjMax for the CE4100 series of Atom CPUs was previously reported to be
    110 degrees C.

    cpuinfo logs on the web show existing CPU types CE4110, CE4150, and CE4170,
    reported as "model name : Intel(R) Atom(TM) CPU CE41{1|5|7}0 @ 1.{2|6}0GHz"
    with model 28 (0x1c) and stepping 10 (0x0a). Add the three known variants
    to the tjmax table.

    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88a9daa1a1d798c6224b35bf6893105511fe2d54
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Jun 17 18:05:05 2012 +0200

    hwmon: (coretemp) Improve support for TjMax detection on Atom CPUs

    commit 41e58a1f2b90c88d94b4bd84beb9927a4c2704e9 upstream.

    Atom CPUs don't have a register to retrieve TjMax. Detection so far was
    incomplete. Use the X86 model ID to improve it.

    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48920d9d2dd4460356c3ad80f944a7e1e285ac2b
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Jun 17 18:05:05 2012 +0200

    hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models

    commit 5592906f8b01282ea3c2acaf641fd067ad4bb3dc upstream.

    Document the Atom series D2000 and N2000 (Cedar Trail) as being supported.
    List and set TjMax for those series.

    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: "R, Durgadoss" <durgadoss.r@intel.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fefdd89a4da69161d75a52d28637a9eb3e92b365
Author: Jean Delvare <khali@linux-fr.org>
Date:   Sun Jun 17 18:05:05 2012 +0200

    hwmon: (coretemp) Improve support of recent Atom CPU models

    commit fcc14ac1a86931f38da047cf8fb634c6db7b58bc upstream.

    Document the new Atom series (Tunnel Creek and Medfield) as being
    supported, and list TjMax for the Atom E600 series.

    Also enable the Atom tjmax heuristic for these Atom CPU models.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Reviewed-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Cc: Alexander Stein <alexander.stein@systec-electronic.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: "R, Durgadoss" <durgadoss.r@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62bde92cc3de3a4af71d5b4203722ed52536fb96
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Nov 26 15:17:50 2013 +0800

    ALSA: hda/realtek - Add support of ALC231 codec

    commit ba4c4d0a9021ab034554d532a98133d668b87599 upstream.

    It's compatible with ALC269.

    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d7772193f6a1125e3da03010496292dc8540646
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 14 15:45:12 2013 +0100

    ALSA: pcsp: Fix the order of input device unregistration

    commit 6408eac2665955343cd0e4bcd7d6237ce39611ed upstream.

    The current code may access to the already freed object.  The input
    device must be accessed and unregistered before freeing the top level
    sound object.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45a823dfec766ffdc0e26ddac622c380ddde216a
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Sun Sep 1 14:36:47 2013 +0300

    ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

    commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

    hdmi_channel_allocation() tries to find a HDMI channel allocation that
    matches the number channels in the playback stream and contains only
    speakers that the HDMI sink has reported as available via EDID. If no
    such allocation is found, 0 (stereo audio) is used.

    Using CA 0 causes the audio causes the sink to discard everything except
    the first two channels (front left and front right).

    However, the sink may be capable of receiving more channels than it has
    speakers (and then perform downmix or discard the extra channels), in
    which case it is preferable to use a CA that contains extra channels
    than to use CA 0 which discards all the non-stereo channels.

    Additionally, it seems that HBR (HD) passthrough output does not work on
    Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
    channels not present in CA). This happens with all receivers that report
    a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
    codec.

    Add a fallback in the CA selection so that the CA channel count at least
    matches the stream channel count, even if the stream contains channels
    not present in the sink speaker descriptor.

    Thanks to GrimGriefer at OpenELEC forums for discovering that changing
    the sink speaker mask allowed HBR output.

    Reported-by: GrimGriefer
    Reported-by: Ashecrow
    Reported-by: Frank Zafka <kafkaesque1978@gmail.com>
    Reported-by: Peter Frühberger <fritsch@xbmc.org>
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d91b2b660587fadc1fc024b67c162192eb449257
Author: Torsten Schenk <torsten.schenk@zoho.com>
Date:   Sun Aug 11 11:11:35 2013 +0200

    ALSA: 6fire: make buffers DMA-able (midi)

    commit 4c2aee0032b70083dafebd733ed9c774633b2fa3 upstream.

    Patch makes midi output buffer DMA-able by allocating it separately.

    Signed-off-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c2e49c8d2f72715511a88216960a17bafb9de55
Author: Torsten Schenk <torsten.schenk@zoho.com>
Date:   Sun Aug 11 11:11:19 2013 +0200

    ALSA: 6fire: make buffers DMA-able (pcm)

    commit 5ece263f1d93fba8d992e67e3ab8a71acf674db9 upstream.

    Patch makes pcm buffers DMA-able by allocating each one separately.

    Signed-off-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c5ac9b7e7eaf7230f0fac69da68d025e58e584b
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue Aug 6 14:53:24 2013 +0300

    ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

    commit ddb6b5a964371e8e52e696b2b258bda144c8bd3f upstream.

    Patch fixes 6fire not to use stack as URB transfer_buffer. URB buffers need to
    be DMA-able, which stack is not. Furthermore, transfer_buffer should not be
    allocated as part of larger device structure because DMA coherency issues and
    patch fixes this issue too.

    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Tested-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf3a0822f1d4145334ed62a4d49e7db47965a1fa
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 26 10:52:20 2013 +0300

    ALSA: ak4xx-adda: info leak in ak4xxx_capture_source_info()

    commit bd5fe738e388ceaa32e5171481e0d3ec59f0ccfe upstream.

    "idx" is controled by the user and can be a negative offset into the
    input_names[] array.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a8182829cc0dc730561708c08ec2e46db20b4b4
Author: Torstein Hegge <hegge@resisty.net>
Date:   Tue Mar 19 17:12:14 2013 +0100

    ALSA: usb: Parse UAC2 extension unit like for UAC1

    commit 61ac51301e6c6d4ed977d7674ce2b8e713619a9b upstream.

    UAC2_EXTENSION_UNIT_V2 differs from UAC1_EXTENSION_UNIT, but can be handled in
    the same way when parsing the unit. Otherwise parse_audio_unit() fails when it
    sees an extension unit on a UAC2 device.

    UAC2_EXTENSION_UNIT_V2 is outside the range allocated by UAC1.

    Signed-off-by: Torstein Hegge <hegge@resisty.net>
    Acked-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 064ad3d2d3d5273f06530bdead922efeb6ce3a32
Author: Eldad Zack <eldad@fogrefinery.com>
Date:   Wed Nov 28 23:55:36 2012 +0100

    ALSA: usb-audio: skip UAC2 EFFECT_UNIT

    commit 5dae5fd24071319bb67d3375217d5b0b6d16cb0b upstream.

    Current code mishandles the case where the device is a UAC2
    and the bDescriptorSubtype is a UAC2 Effect Unit (0x07).
    It tries to parse it as a Processing Unit (which is similar to two
    other UAC1 units with overlapping subtypes), but since the structure
    is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing
    is done incorrectly and prevents the device from initializing.
    For now, just ignore the unit.

    Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 559ea4c783d9f152e27ef058ca72375acc69f538
Author: Aaron Plattner <aplattner@nvidia.com>
Date:   Fri Jul 12 11:01:37 2013 -0700

    ALSA: hda - Add another GPU codec ID to snd-hda

    commit d52392b1a80458c0510810789c7db4a39b88022a upstream.

    Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip.

    Reviewed-by: Andy Ritger <aritger@nvidia.com>
    Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fe813db78ece249ac98df8a8af921d2abf62d2f
Author: Aaron Plattner <aplattner@nvidia.com>
Date:   Mon Jul 16 17:10:04 2012 -0700

    ALSA: hda - Add new GPU codec ID to snd-hda

    commit 7ae48b56f8d9c836259bc02f3e2ea4962d6b5d1b upstream.

    Vendor ID 0x10de0051 is used by a yet-to-be-named GPU chip.

    Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
    Acked-by: Andy Ritger <aritger@nvidia.com>
    Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dfbe364554ffd86201a4769a2be8847bf12ac41
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jun 18 16:14:22 2013 +0200

    ALSA: hda - Cache the MUX selection for generic HDMI

    commit bddee96b5d0db869f47b195fe48c614ca824203c upstream.

    When a selection to a converter MUX is changed in hdmi_pcm_open(), it
    should be cached so that the given connection can be restored properly
    at PM resume.  We need just to replace the corresponding
    snd_hda_codec_write() call with snd_hda_codec_write_cache().

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f29ecd7c7ab4db1fd968cf70ba2b538f841a9672
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Dec 9 14:53:36 2013 +0100

    xhci: Limit the spurious wakeup fix only to HP machines

    commit 6962d914f317b119e0db7189199b21ec77a4b3e0 upstream.

    We've got regression reports that my previous fix for spurious wakeups
    after S5 on HP Haswell machines leads to the automatic reboot at
    shutdown on some machines.  It turned out that the fix for one side
    triggers another BIOS bug in other side.  So, it's exclusive.

    Since the original S5 wakeups have been confirmed only on HP machines,
    it'd be safer to apply it only to limited machines.  As a wild guess,
    limiting to machines with HP PCI SSID should suffice.

    This patch should be backported to kernels as old as 3.12, that
    contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix
    spurious wakeups after S5 on Haswell".

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: <dashing.meng@gmail.com>
    Reported-by: Niklas Schnelle <niklas@komani.de>
    Reported-by: Giorgos <ganastasiouGR@gmail.com>
    Reported-by: <art1@vhex.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72f76957fe6c09302b69f6c920d157dc55e2bd9c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 12 08:11:06 2013 +0200

    xhci: Fix spurious wakeups after S5 on Haswell

    commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 upstream.

    Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
    mysterious wakeups after shutdown occasionally.  After discussing with
    BIOS engineers, they explained that the new BIOS expects that the
    wakeup sources are cleared and set to D3 for all wakeup devices when
    the system is going to sleep or power off, but the current xhci driver
    doesn't do this properly (partly intentionally).

    This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
    fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
    shutdown ops as done in xhci_stop(), and setting the device to PCI D3
    at shutdown and remove ops.

    The PCI D3 call is based on the initial fix patch by Oliver Neukum.

    [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
    XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
    in them.  Sarah also fixed a collision with a quirk submitted around the
    same time, by changing the xhci->quirks bit from 17 to 18.]

    This patch should be backported to kernels as old as 3.0, that
    contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add
    Lynx Point to list of Intel switchable hosts."

    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1dad63b18c79c3249a46c24c20d22a190ba2e49
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Sep 30 15:50:54 2013 +0200

    xhci: quirk for extra long delay for S4

    commit 455f58925247e8a1a1941e159f3636ad6ee4c90b upstream.

    It has been reported that this chipset really cannot
    sleep without this extraordinary delay.

    This patch should be backported, in order to ensure this host functions
    under stable kernels.  The last quirk for Fresco Logic hosts (commit
    bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
    quirk.") was backported to stable kernels as old as 2.6.36.

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use xhci_dbg() instead of xhci_dbg_trace()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yangyl: Backported to 3.4: Adjust context]
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17fafb821b5a566ba104304ad18e26f3a518ccca
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Oct 15 17:45:00 2013 -0700

    usb: hub: Clear Port Reset Change during init/resume

    commit e92aee330837e4911553761490a8fb843f2053a6 upstream.

    This patch adds the Port Reset Change flag to the set of bits that are
    preemptively cleared on init/resume of a hub. In theory this bit should
    never be set unexpectedly... in practice it can still happen if BIOS,
    SMM or ACPI code plays around with USB devices without cleaning up
    correctly. This is especially dangerous for XHCI root hubs, which don't
    generate any more Port Status Change Events until all change bits are
    cleared, so this is a good precaution to have (similar to how it's
    already done for the Warm Port Reset Change flag).

    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/usb_clear_port_feature/clear_port_feature/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yangyl: Backported to 3.4: Adjust context]
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 641c063b6606cda4b5d1bbf72762c4d1f90ba2f7
Author: James Ralston <james.d.ralston@intel.com>
Date:   Mon Nov 4 09:24:58 2013 -0800

    ahci: Add Device IDs for Intel Wildcat Point-LP

    commit 9f961a5f6efc87a79571d7166257b36af28ffcfe upstream.

    This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH.

    Signed-off-by: James Ralston <james.d.ralston@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 421f12fe9a8fd02f3806f458c7a4dee3c19147bb
Author: Seth Heasley <seth.heasley@intel.com>
Date:   Wed Jun 19 16:36:45 2013 -0700

    ahci: AHCI-mode SATA patch for Intel Coleto Creek DeviceIDs

    commit 1cfc7df3de10c40ed459e13cce6de616023bf41c upstream.

    This patch adds the AHCI-mode SATA DeviceIDs for the Intel Coleto Creek PCH.

    Signed-off-by: Seth Heasley <seth.heasley@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e6983787f309f2c2c1087cdf2ca59bcf32896ba
Author: James Ralston <james.d.ralston@intel.com>
Date:   Fri Feb 8 17:34:47 2013 -0800

    ahci: Add Device IDs for Intel Wellsburg PCH

    commit 151743fd8dfb02956c5184b5f4f0f42677eb75bc upstream.

    This patch adds the AHCI-mode SATA Device IDs for the Intel Wellsburg PCH

    Signed-off-by: James Ralston <james.d.ralston@intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 641eccff6d815c3827cd3fd5d0816d954171d9df
Author: Colin Leitner <colin.leitner@googlemail.com>
Date:   Tue Nov 5 18:02:34 2013 +0100

    USB: ftdi_sio: fixed handling of unsupported CSIZE setting

    commit 8704211f65a2106ba01b6ac9727cdaf9ca11594c upstream.

    FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would
    only report this limitation for CS6 to dmesg and fail to reflect this fact to
    tcgetattr.

    This patch reverts the unsupported CSIZE setting and reports the fact with less
    severance to dmesg for both CS5 and CS6.

    To test the patch it's sufficient to call

        stty -F /dev/ttyUSB0 cs5

    which will succeed without the patch and report an error with the patch
    applied.

    As an additional fix this patch ensures that the control request will always
    include a data bit size.

    Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2:
     - Old code is cosmetically different
     - s/ddev/\&port->dev/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8af2652a0921e825a1988f2ab2277de9a691bf73
Author: Thomas Pugliese <thomas.pugliese@gmail.com>
Date:   Wed Oct 23 14:44:29 2013 -0500

    usb: wusbcore: change WA_SEGS_MAX to a legal value

    commit f74b75e7f920c700636cccca669c7d16d12e9202 upstream.

    change WA_SEGS_MAX to a number that is legal according to the WUSB
    spec.

    Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f17c3eb72e0607fe9a7757a6e8227d2235d13c81
Author: Thomas Pugliese <thomas.pugliese@gmail.com>
Date:   Wed Oct 23 14:44:26 2013 -0500

    usb: wusbcore: set the RPIPE wMaxPacketSize value correctly

    commit 7b6bc07ab554e929c85d51b3d5b26cf7f12c6a3b upstream.

    For isochronous endpoints, set the RPIPE wMaxPacketSize value using
    wOverTheAirPacketSize from the endpoint companion descriptor instead of
    wMaxPacketSize from the normal endpoint descriptor.

    Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf52ab9fb3021b8eaedcec4b6751cb898a4d6b94
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Thu Sep 26 13:01:44 2013 -0700

    usb: dwc3: add support for Merrifield

    commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

    Add PCI id for Intel Merrifield

    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f0c779d29f98a1d9e0c07e632b2bf2584c5ba6d
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue Sep 17 10:38:13 2013 +0300

    usb: dwc3: pci: add support for BayTrail

    commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

    Add PCI id for Intel BayTrail.

    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38a1167bc275c1a3637333ff806d11ea66987e07
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Sep 30 17:26:29 2013 +0300

    usb: Disable USB 2.0 Link PM before device reset.

    commit dcc01c0864823f91c3bf3ffca6613e2351702b87 upstream.

    Before the USB core resets a device, we need to disable the L1 timeout
    for the roothub, if USB 2.0 Link PM is enabled.  Otherwise the port may
    transition into L1 in between descriptor fetches, before we know if the
    USB device descriptors changed.  LPM will be re-enabled after the
    full device descriptors are fetched, and we can confirm the device still
    supports USB 2.0 LPM after the reset.

    We don't need to wait for the USB device to exit L1 before resetting the
    device, since the xHCI roothub port diagrams show a transition to the
    Reset state from any of the Ux states (see Figure 34 in the 2012-08-14
    xHCI specification update).

    This patch should be backported to kernels as old as 3.2, that contain
    the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
    hardware LPM".  That was the first commit to enable USB 2.0
    hardware-driven Link Power Management.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 690914b7caffe9bd855ad991dfff8fa4932438d7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 24 15:45:25 2013 -0400

    USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

    commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream.

    Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
    field in their pci_driver structures should be protected by CONFIG_PM
    rather than CONFIG_PM_SLEEP.  The corresponding change has already
    been made for ohci-hcd.

    Without this change, controllers won't do runtime suspend if system
    suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40a1a0d6c98b4eb90ec1550bc9367a60829b86e5
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 30 10:46:00 2013 -0400

    USB: fix build error when CONFIG_PM_SLEEP isn't enabled

    commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

    This patch fixes a build error that occurs when CONFIG_PM is enabled
    and CONFIG_PM_SLEEP isn't:

    >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
          .pm = &usb_hcd_pci_pm_ops

    Since the usb_hcd_pci_pm_ops structure is defined and used when
    CONFIG_PM is enabled, its declaration should not be protected by
    CONFIG_PM_SLEEP.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 203ee125f0e7f4450c5876057aa87fe8b76b6f63
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 26 15:01:40 2013 -0400

    USB: OHCI: Allow runtime PM without system sleep

    commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

    Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
    structure should be protected by CONFIG_PM rather than
    CONFIG_PM_SLEEP.

    Without this change, OHCI controllers won't do runtime suspend if
    system suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aeb21d987532c54a7191d50d305f670e0dcc8e6
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Aug 13 13:27:35 2013 +0200

    USB: keyspan: fix null-deref at disconnect and release

    commit ff8a43c10f1440f07a5faca0c1556921259f7f76 upstream.

    Make sure to fail properly if the device is not accepted during attach
    in order to avoid null-pointer derefs (of missing interface private
    data) at disconnect or release.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8da80c590e6709bf4c167631d76251f97cb2433c
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Aug 11 16:49:23 2013 +0200

    USB: ti_usb_3410_5052: fix big-endian firmware handling

    commit e877dd2f2581628b7119df707d4cf03d940cff49 upstream.

    Fix endianess bugs in firmware handling introduced by commits cb7a7c6a
    ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905
    ("ti_usb_3410_5052: support alternate firmware") which made the driver
    use the wrong firmware for certain devices on big-endian machines.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f903cc35d43eb82a75c6dc51fa5150e3da3253
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Aug 11 16:49:22 2013 +0200

    USB: adutux: fix big-endian device-type reporting

    commit d482b9d558602a9cacab063b1c8779f9b5214da7 upstream.

    Make sure the reported device-type on big-endian machines is the same as
    on little-endian ones.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 273f0fe73a3746cb2366023e29e08d8925b13995
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jul 26 11:55:17 2013 +0200

    USB: mos7840: fix race in register handling

    commit d8a083cc746664916d9d36ed9e4d08a29525f245 upstream.

    Fix race in mos7840_get_reg which unconditionally manipulated the
    control urb (which may already be in use) by adding a control-urb busy
    flag.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c0985751e9471cca8add3b9e86eb70bd9985584
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jul 1 14:03:33 2013 +0200

    USB: mos7840: fix memory leak in open

    commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 upstream.

    Allocated urbs and buffers were never freed on errors in open.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0e76de9d1127df455f4ae9a210a79c33df08c7a
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jun 10 18:29:38 2013 +0200

    USB: pl2303: fix device initialisation at open

    commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream.

    Do not use uninitialised termios data to determine when to configure the
    device at open.

    This also prevents stack data from leaking to userspace in the OOM error
    path.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac6c8362f15dc0d6ee3116a1116fd4747a22f992
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jun 10 18:29:39 2013 +0200

    USB: spcp8x5: fix device initialisation at open

    commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream.

    Do not use uninitialised termios data to determine when to configure the
    device at open.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f9ce2de515cde02cf2db71fe0320fe0b5d99383
Author: Richard Weinberger <richard@nod.at>
Date:   Fri May 24 12:01:51 2013 +0200

    USB: serial: Add Option GTM681W to qcserial device table.

    commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream.

    The Option GTM681W uses a qualcomm chip and can be
    served by the qcserial device driver.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b43be188e07a1be4566d35ad7639eeaeddab17a
Author: George Cherian <george.cherian@ti.com>
Date:   Mon May 27 14:35:49 2013 +0530

    usb: dwc3: gadget: free trb pool only from epnum 2

    commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 upstream.

    we never allocate a TRB pool for physical endpoints
    0 and 1 so trying to free it (a invalid TRB pool pointer)
    will lead us in a warning while removing dwc3.ko module.

    In order to fix the situation, all we have to do is skip
    dwc3_free_trb_pool() for physical endpoints 0 and 1 just
    as we while deleting endpoints from the endpoints list.

    Signed-off-by: George Cherian <george.cherian@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06791ac363feb9640926f16dd3c2e71d9b7c7350
Author: Adrian Thomasset <adrian.thomasset@st.com>
Date:   Wed Apr 24 11:37:35 2013 +0100

    USB: ftdi_sio: enable two UART ports on ST Microconnect Lite

    commit 71d9a2b95fc9c9474d46d764336efd7a5a805555 upstream.

    The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
    The first two ports are reserved for the JTAG interface.

    We enable by default ports 2 and 3 as UARTs (where port 2 is a
    conventional RS-232 UART)

    Signed-off-by: Adrian Thomasset <adrian.thomasset@st.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e806200d8d50ab132742b5faa63741e8aecc9c2d
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Tue Mar 26 10:49:55 2013 +0800

    USB: serial: fix hang when opening port

    commit eba0e3c3a0ba7b96f01cbe997680f6a4401a0bfc upstream.

    Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces
    one bug which can cause kernel hang when opening port.

    This patch initialized the 'port->delta_msr_wait' waitqueue head
    to fix the bug which is introduced in 3.9-rc4.

    [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2

    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Acked-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbb350cfb8ce68d14e0accfefdbc543222aecb80
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:26 2013 +0100

    USB: ti_usb_3410_5052: fix use-after-free in TIOCMIWAIT

    commit 3668b9c17765cacf411effc4fc6e44099ac30800 upstream.

    commit fc98ab873aa3dbe783ce56a2ffdbbe7c7609521a upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7182ca4f819988f9aeda173f0168ec3f0d98d548
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:25 2013 +0100

    USB: ssu100: fix use-after-free in TIOCMIWAIT

    commit 43a66b4c417ad15f6d2f632ce67ad195bdf999e8 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcaa73a2c28d563e45148935fe2e2c4b4c269908
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:24 2013 +0100

    USB: spcp8x5: fix use-after-free in TIOCMIWAIT

    commit d1baabc8006fd238ad8da4d734dc815a8de02362 upstream.

    commit dbcea7615d8d7d58f6ff49d2c5568113f70effe9 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3670a5f63bff42ce602d27073fed248723f1a43
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:22 2013 +0100

    USB: pl2303: fix use-after-free in TIOCMIWAIT

    commit 40509ca982c00c4b70fc00be887509feca0bff15 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66aa05b0e98bbee4e6549399a29083df77723bed
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:21 2013 +0100

    USB: oti6858: fix use-after-free in TIOCMIWAIT

    commit 8edfdab37157d2683e51b8be5d3d5697f66a9f7b upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bcfe385095eb44ef90a3c879ba017d055a1aa40
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:20 2013 +0100

    USB: mos7840: fix use-after-free in TIOCMIWAIT

    commit a14430db686b8e459e1cf070a6ecf391515c9ab9 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba3ab346d5e19f8d519f99b1b777e85dcd099e6e
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:19 2013 +0100

    USB: mos7840: fix broken TIOCMIWAIT

    commit e670c6af12517d08a403487b1122eecf506021cf upstream.

    Make sure waiting processes are woken on modem-status changes.

    Currently processes are only woken on termios changes regardless of
    whether the modem status has changed.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e71fdba2944a2d6756fc546ae1ed2fbadd4bc9f4
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:18 2013 +0100

    USB: mct_u232: fix use-after-free in TIOCMIWAIT

    commit cf1d24443677a0758cfa88ca40f24858b89261c0 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f681344871a30613f622a85f396e0a467c4947a1
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:17 2013 +0100

    USB: io_ti: fix use-after-free in TIOCMIWAIT

    commit 7b2459690584f239650a365f3411ba2ec1c6d1e0 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fe7941d648c9463e7e3dcfea484d2ecfca01df3
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:16 2013 +0100

    USB: io_edgeport: fix use-after-free in TIOCMIWAIT

    commit 333576255d4cfc53efd056aad438568184b36af6 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbce9666fcef334c846c3819b522d375a3306742
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:15 2013 +0100

    USB: ftdi_sio: fix use-after-free in TIOCMIWAIT

    commit 71ccb9b01981fabae27d3c98260ea4613207618e upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    When switching to tty ports, some lifetime assumptions were changed.
    Specifically, close can now be called before the final tty reference is
    dropped as part of hangup at device disconnect. Even with the ftdi
    private-data refcounting this means that the port private data can be
    freed while a process is sleeping on modem-status changes and thus
    cannot be relied on to detect disconnects when woken up.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8828136d0f15f3a6084cf375cf6a2b653055bf6d
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:13 2013 +0100

    USB: cypress_m8: fix use-after-free in TIOCMIWAIT

    commit 356050d8b1e526db093e9d2c78daf49d6bf418e3 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Also remove bogus test for private data pointer being NULL as it is
    never assigned in the loop.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d12b2a2e2baa6323b3a0d27103772687236e9843
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:12 2013 +0100

    USB: ch341: fix use-after-free in TIOCMIWAIT

    commit fa1e11d5231c001c80a479160b5832933c5d35fb upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 508aa8751dc3637ffafe809bcd40f9b40a39c60c
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:11 2013 +0100

    USB: ark3116: fix use-after-free in TIOCMIWAIT

    commit 5018860321dc7a9e50a75d5f319bc981298fb5b7 upstream.

    Use the port wait queue and make sure to check the serial disconnected
    flag before accessing private port data after waking up.

    This is is needed as the private port data (including the wait queue
    itself) can be gone when waking up after a disconnect.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3d5d20cbd16bd778d35a675415d939e84eee00f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Mar 19 09:21:10 2013 +0100

    USB: serial: add modem-status-change wait queue

    commit e5b33dc9d16053c2ae4c2c669cf008829530364b upstream.

    Add modem-status-change wait queue to struct usb_serial_port that
    subdrivers can use to implement TIOCMIWAIT.

    Currently subdrivers use a private wait queue which may have been
    released when waking up after device disconnected.

    Note that we're adding a new wait queue rather than reusing the tty-port
    one as we do not want to get woken up at hangup (yet).

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0fd860104dc478a5ca73f70e09dc951eff0f399
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 14 10:22:35 2012 +0100

    ALSA: hda - Always turn on pins for HDMI/DP

    commit 6169b673618bf0b2518ce413b54925782a603f06 upstream.

    We've seen the broken HDMI *video* output on some machines with GM965,
    and the debugging session pointed that the culprit is the disabled
    audio output pins.  Toggling these pins dynamically on demand caused
    flickering of HDMI TV.

    This patch changes the behavior to keep the pin ON constantly.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0283a8e64d191065f2ac0945b1cf790efc07365
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Dec 19 09:44:47 2012 +0100

    Revert "ALSA: hda - Shut up pins at power-saving mode with Conexnat codecs"

    commit 7ed4165e2d01bdbbb4c1086eb73eadf0f64cbbf0 upstream.

    This reverts commit 697c373e34613609cb5450f98b91fefb6e910588.

    The original patch was meant to remove clicking, but in fact caused even
    more clicking instead.

    Thanks to c4pp4 for doing most of the work with this bug.

    BugLink: https://bugs.launchpad.net/bugs/886975
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21bbdbe8739fb3ca005e5f21919d0b69452da541
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu May 10 08:54:23 2012 +0200

    ALSA: hda - Add Conexant CX20751/2/3/4 codec support

    commit 61d648fb4726f8a89c07cd1904f9c2e11bf26df5 upstream.

    These are almost compatible with the older Conexant codecs.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4bcf8a65496812952739ccdeca00f4f84607471
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 29 18:07:22 2013 +0100

    ALSA: hda - Fix non-snoop page handling

    commit 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a upstream.

    For non-snoop mode, we fiddle with the page attributes of CORB/RIRB
    and the position buffer, but also the ring buffers.  The problem is
    that the current code blindly assumes that the buffer is contiguous.
    However, the ring buffers may be SG-buffers, thus a wrong vmapped
    address is passed there, leading to Oops.

    This patch fixes the handling for SG-buffers.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=800701

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: open-code snd_pcm_get_dma_buf()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06c66ad25f0604f6de44db5241f7e98bbf724148
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 4 10:28:15 2013 +0100

    ALSA: aloop: Fix Oops while PM resume

    commit edac894389f9c9de2a1368c78809c824b343f3a5 upstream.

    snd-aloop driver has no proper PM implementation, thus the PM resume
    may trigger Oops due to leftover timer instance.  This patch adds the
    missing suspend/resume implementation.

    Reported-and-tested-by: El boulangero <elboulangero@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09a0a93e23564ed1e2e485b2838292c32b46dfb5
Author: Calvin Owens <jcalvinowens@gmail.com>
Date:   Fri Apr 12 22:33:59 2013 -0500

    ALSA: usb: Add quirk for 192KHz recording on E-Mu devices

    commit 1539d4f82ad534431cc67935e8e442ccf107d17d upstream.

    When recording at 176.2KHz or 192Khz, the device adds a 32-bit length
    header to the capture packets, which obviously needs to be ignored for
    recording to work properly.

    Userspace expected:  L0 L1 L2 R0 R1 R2
    ...but actually got: R2 L0 L1 L2 R0 R1

    Also, the last byte of the length header being interpreted as L0 of
    the first sample caused spikes every 0.5ms, resulting in a loud 16KHz
    tone (about the highest 'B' on a piano) being present throughout
    captures.

    Tested at all sample rates on an E-Mu 0404USB, and tested for
    regressions on a generic USB headset.

    Signed-off-by: Calvin Owens <jcalvinowens@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust filenames, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 451a020e8836d9d28a4452ce0f36d187260b730f
Author: Andreas Fleig <andreasfleig@gmail.com>
Date:   Wed Dec 5 16:17:49 2012 +0100

    USB: Add device quirk for Microsoft VX700 webcam

    commit bc009eca8d539162f7271c2daf0ab5e9e3bb90a0 upstream.

    Add device quirk for Microsoft Lifecam VX700 v2.0 webcams.
    Fixes squeaking noise of the microphone.

    Signed-off-by: Andreas Fleig <andreasfleig@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5f899bb5c9f2cedc58d2187b824167dbfbb0594
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Nov 8 10:17:01 2012 -0500

    USB: EHCI: bugfix: urb->hcpriv should not be NULL

    commit 2656a9abcf1ec8dd5fee6a75d6997a0f2fa0094e upstream.

    This patch (as1632b) fixes a bug in ehci-hcd.  The USB core uses
    urb->hcpriv to determine whether or not an URB is active; host
    controller drivers are supposed to set this pointer to a non-NULL
    value when an URB is queued.  However ehci-hcd sets it to NULL for
    isochronous URBs, which defeats the check in usbcore.

    In itself this isn't a big deal.  But people have recently found that
    certain sequences of actions will cause the snd-usb-audio driver to
    reuse URBs without waiting for them to complete.  In the absence of
    proper checking by usbcore, the URBs get added to their endpoint list
    twice.  This leads to list corruption and a system freeze.

    The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for
    isochronous URBs.  Improving robustness always helps.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Artem S. Tashkinov <t.artem@lycos.com>
    Reported-by: Christof Meerwald <cmeerw@cmeerw.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - Also use usb_pipetype() to work out whether we should call qh_put()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 623c2d0b5ecec2562ba6760737f07e44475eb451
Author: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Date:   Thu Oct 25 17:11:31 2012 +0530

    ath9k_hw: Enable hw PLL power save for AR9462

    commit 1680260226a8fd2aab590319da83ad8e610da9bd upstream.

    This reduced the power consumption to half in full and network sleep.

    Cc: Paul Stewart <pstew@chromium.org>
    Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2:
     - INIT_INI_ARRAY macro requires an explicit size argument
     - Remove the now-redundant macro PCIE_PLL_ON_CREQ_DIS_L1_2P0]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e2025b81640b8a3cfdfa701c9ffa3c96a54932f
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Wed Dec 26 12:27:39 2012 +0530

    ath9k_hw: Fix RX gain initvals for AR9485

    commit a796a1dd5da9645ad77aa687d1a890ecd63ab5a6 upstream.

    Populate iniModesRxGain with the correct initvals
    array for AR9485 v1.1

    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
     - INIT_INI_ARRAY takes additional size and columns arguments]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe9ae72ae8cd842e91637f8a2ad8889072224399
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Jan 20 21:55:21 2013 +0100

    ath9k_hw: fix chain swap setting when setting rx chainmask to 5

    commit 959f049dfb62b517cbb3dd48ed2fb7d9c713ce16 upstream.

    commit 24171dd92096fc370b195f3f6bdc0798855dc3f9 upstream.

    Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
    regardless of what the runtime chainmask is.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: keep the special case for AR_SREV_9462 here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c9fc45520abe27ab366a5a32e323e2aa6fab57d
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Feb 22 21:37:25 2013 +0100

    ath9k_htc: fix signal strength handling issues

    commit 838f427955dcfd16858b0108ce29029da0d56a4e upstream.

    The ath9k commit 2ef167557c0a26c88162ecffb017bfcc51eb7b29
    (ath9k: fix signal strength reporting issues) fixed an issue where the
    reported per-frame signal strength reported to mac80211 was being
    overwritten with an internal average. The same issue is also present
    in ath9k_htc.
    In addition to preventing the driver from overwriting the value, this
    commit also ensures that the internal average (which is used for ANI)
    only tracks beacons of the AP that we're connected to.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: use compare_ether_addr() instead of
     ether_addr_equal(), with opposite sense]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 995fb76fffe77a2d897689bd02f63ea88f17691d
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Mon Jun 10 13:49:38 2013 +0530

    ath9k_hw: Assign default xlna config for AR9485

    commit 30d5b709da23f4ab9836c7f66d2d2e780a69cf12 upstream.

    For AR9485 boards with XLNA, the default gpio config
    is not set correctly, fix this.

    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>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a257c5ca18d97b91846cd89a8b069ae4177cd80a
Author: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Date:   Fri Oct 12 14:07:24 2012 +0530

    ath9k: fill channel mode in caldata

    commit 77d848372875d2e4cbdbf07030f0e08cab5e7f4d upstream.

    It is useful to have channel mode in caldata to find out
    whether operaing channel is in HT40/20 when we are currently
    on offchannel. It will be used by BTCOEX to enable/disable
    concurrent tx mechanism later.

    Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d77cd3020f60215537d069432281a7575bc39269
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Mon Jun 10 13:49:39 2013 +0530

    ath9k: Fix noisefloor calibration

    commit 696df78509d1f81b651dd98ecdc1aecab616db6b upstream.

    The commits,

    "ath9k: Fix regression in channelwidth switch at the same channel"
    "ath9k: Fix invalid noisefloor reading due to channel update"

    attempted to fix noisefloor calibration when a channel switch
    happens due to HT20/HT40 bandwidth change. This is causing invalid
    readings resulting in messages like:

    "ath: phy16: NF[0] (-45) > MAX (-95), correcting to MAX".

    This results in an incorrect noise being used initially for reporting
    the signal level of received packets, until NF calibration is done
    and the history buffer is updated via the ANI timer, which happens
    much later.

    When a bandwidth change happens, it is appropriate to reset
    the internal history data for the channel. Do this correctly in the
    reset() routine by checking the "chanmode" variable.

    Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    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, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25df061cc883e5732552538bf84265f0e9705a7b
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Jul 25 11:44:48 2013 +0100

    ARM: 7791/1: a.out: remove partial a.out support

    commit acfdd4b1f7590d02e9bae3b73bdbbc4a31b05d38 upstream.

    a.out support on ARM requires that argc, argv and envp are passed in
    r0-r2 respectively, which requires hacking load_aout_binary to
    prevent argc being clobbered by the return code. Whilst mainline kernels
    do set the registers up in start_thread, the aout loader has never
    carried the hack in mainline.

    Initialising the registers in this way actually goes against the libc
    expectations for ELF binaries, where argc, argv and envp are passed on
    the stack, with r0 being used to hold a pointer to an exit function for
    cleaning up after the dynamic linker if required. If the pointer is
    NULL, then it is ignored. When execing an ELF binary, Linux currently
    zeroes r0, then sets it to argc and then finally clobbers it with the
    return value of the execve syscall, so we actually end up with:

    	r0 = 0
    	stack[0] = argc
    	r1 = stack[1] = argv
    	r2 = stack[2] = envp

    libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
    works for user-spawned threads, but when executing an ELF binary from a
    kernel thread (via call_usermodehelper), the execve is performed on the
    ret_from_fork path, which restores r0 from the saved pt_regs, resulting
    in argc being presented to the C library. This has horrible consequences
    when the application exits, since we have an exit function registered
    using argc, resulting in a jump to hyperspace.

    This patch solves the problem by removing the partial a.out support from
    arch/arm/ altogether.

    Cc: Ashish Sangwan <ashishsangwan2@gmail.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:
     - Adjust context
     - Adjust uapi filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yangyl: Backported to 3.4: Adjust context]
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1de89d19c5aad88c96ff2aac7b326a04da06292b
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Jan 15 18:51:32 2013 +0100

    ARM: 7628/1: head.S: map one extra section for the ATAG/DTB area

    commit 6f16f4998f98e42e3f2dedf663cfb691ff0324af upstream.

    We currently use a temporary 1MB section aligned to a 1MB boundary for
    mapping the provided device tree until the final page table is created.
    However, if the device tree happens to cross that 1MB boundary, the end
    of it remains unmapped and the kernel crashes when it attempts to access
    it.  Given no restriction on the location of that DTB, it could end up
    with only a few bytes mapped at the end of a section.

    Solve this issue by mapping two consecutive sections.

    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
    Tested-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [bwh: Backported to 3.2:
     - Adjust context
     - The mapping is not conditional; drop the 'ne' suffixes]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yangyl: Backported to 3.4: Adjust context]
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06a5d6e49a4a9a4c6fc14b15ed3b5974192a4937
Author: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Date:   Thu Jul 26 12:15:46 2012 +0200

    ARM: Orion: Set eth packet size csum offload limit

    commit 58569aee5a1a5dcc25c34a0a2ed9a377874e6b05 upstream.

    The mv643xx ethernet controller limits the packet size for the TX
    checksum offloading. This patch sets this limits for Kirkwood and
    Dove which have smaller limits that the default.

    As a side note, this patch is an updated version of a patch sent some years
    ago: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017320.html
    which seems to have been lost.

    Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    [bwh: Backported to 3.2: adjust for the extra two parameters of
     orion_ge0{0,1}_init()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yangyl: Backported to 3.4: Adjust context]
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c951fd220e79967a5a72ccf3a5cfcb4e9d56421
Author: Sergei Ianovich <ynvich@gmail.com>
Date:   Tue Dec 10 08:39:15 2013 +0400

    ARM: pxa: prevent PXA270 occasional reboot freezes

    commit ff88b4724fde18056a4c539f7327389aec0f4c2d upstream.

    Erratum 71 of PXA270M Processor Family Specification Update
    (April 19, 2010) explains that watchdog reset time is just
    8us insead of 10ms in EMTS.

    If SDRAM is not reset, it causes memory bus congestion and
    the device hangs. We put SDRAM in selfresh mode before watchdog
    reset, removing potential freezes.

    Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40
    reboots. With this patch it has successfully rebooted 500 times.

    Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
    Tested-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db80eec862aade7dfdaa63fe40c0e77cd6297fa6
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Nov 28 21:55:41 2013 +0000

    ARM: footbridge: fix VGA initialisation

    commit 43659222e7a0113912ed02f6b2231550b3e471ac upstream.

    It's no good setting vga_base after the VGA console has been
    initialised, because if we do that we get this:

    Unable to handle kernel paging request at virtual address 000b8000
    pgd = c0004000
    [000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000
    0Internal error: Oops: 5017 [#1] ARM
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
    task: c03e2974 ti: c03d8000 task.ti: c03d8000
    PC is at vgacon_startup+0x258/0x39c
    LR is at request_resource+0x10/0x1c
    pc : [<c01725d0>]    lr : [<c0022b50>]    psr: 60000053
    sp : c03d9f68  ip : 000b8000  fp : c03d9f8c
    r10: 000055aa  r9 : 4401a103  r8 : ffffaa55
    r7 : c03e357c  r6 : c051b460  r5 : 000000ff  r4 : 000c0000
    r3 : 000b8000  r2 : c03e0514  r1 : 00000000  r0 : c0304971
    Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel

    which is an access to the 0xb8000 without the PCI offset required to
    make it work.

    Fixes: cc22b4c18540 ("ARM: set vga memory base at run-time")
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87e30f18047e0887643791aba36f253a137d3aa0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:50:47 2013 +0100

    ARM: 7743/1: compressed/head.S: work around new binutils warning

    commit da94a829305f1c217cfdf6771cb1faca0917e3b9 upstream.

    In August 2012, Matthew Gretton-Dann checked a change into binutils
    labelled "Error on obsolete & warn on deprecated registers", apparently as
    part of ARMv8 support. Apparently, this was supposed to emit the message
    "Warning: This coprocessor register access is deprecated in ARMv8" when
    using certain mcr/mrc instructions and building for ARMv8. Unfortunately,
    the message that is actually emitted appears to be '(null)', which is
    less helpful in comparison.

    Even more unfortunately, this is biting us on every single kernel
    build with a new gas, because arch/arm/boot/compressed/head.S and some
    other files in that directory are built with -march=all since kernel
    commit 80cec14a8 "[ARM] Add -march=all to assembly file build in
    arch/arm/boot/compressed" back in v2.6.28.

    This patch reverts Russell's nice solution and instead marks the head.S
    file to be built for armv7-a, which fortunately lets us build all
    instructions in that file without warnings even on the broken binutils.

    Without this patch, building anything results in:

    arch/arm/boot/compressed/head.S: Assembler messages:
    arch/arm/boot/compressed/head.S:565: Warning: (null)
    arch/arm/boot/compressed/head.S:676: Warning: (null)
    arch/arm/boot/compressed/head.S:698: Warning: (null)
    arch/arm/boot/compressed/head.S:722: Warning: (null)
    arch/arm/boot/compressed/head.S:726: Warning: (null)
    arch/arm/boot/compressed/head.S:957: Warning: (null)
    arch/arm/boot/compressed/head.S:996: Warning: (null)
    arch/arm/boot/compressed/head.S:997: Warning: (null)
    arch/arm/boot/compressed/head.S:1027: Warning: (null)
    arch/arm/boot/compressed/head.S:1035: Warning: (null)
    arch/arm/boot/compressed/head.S:1046: Warning: (null)
    arch/arm/boot/compressed/head.S:1060: Warning: (null)
    arch/arm/boot/compressed/head.S:1092: Warning: (null)
    arch/arm/boot/compressed/head.S:1094: Warning: (null)
    arch/arm/boot/compressed/head.S:1095: Warning: (null)
    arch/arm/boot/compressed/head.S:1102: Warning: (null)
    arch/arm/boot/compressed/head.S:1134: Warning: (null)

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [bwh: Backported to 3.2:
     - Adjust context
     - Remove definition of asflags-y as it is now empty]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7647dbd225afe04bc2294992c6503fe8d4387760
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:49:22 2013 +0100

    ARM: 7742/1: topology: export cpu_topology

    commit 92bdd3f5eba299b33c2f4407977d6fa2e2a6a0da upstream.

    The cpu_topology symbol is required by any driver using the topology
    interfaces, which leads to a couple of build errors:

    ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
    ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
    ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

    The obvious solution is to export this symbol.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Nicolas Pitre <nico@linaro.org>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3779a72ea5031e81e43565fb4291eab4c9269437
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Apr 26 15:29:55 2013 +0200

    ARM: u300: fix ages old copy/paste bug

    commit 0259d9eb30d003af305626db2d8332805696e60d upstream.

    The UART1 is on the fast AHB bridge, not on the slow bus.

    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b6a5129b536186bdf88412a069a73e005fe6438
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 14 12:49:02 2013 +0000

    ARM: w90x900: fix legacy assembly syntax

    commit fa5ce5f94c0f2bfa41ba68d2d2524298e1fc405e upstream.

    New ARM binutils don't allow extraneous whitespace inside
    of brackets, which causes this error on all mach-w90x900
    defconfigs:

    arch/arm/kernel/entry-armv.S: Assembler messages:
    arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
    arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
    arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
    arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'

    This removes the whitespace in order to build the kernel
    again.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Wan ZongShun <mcuos.com@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef42bb5717ba0e8645f7be6399643405f40331ee
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Wed Aug 22 21:46:39 2012 +0800

    ARM: dts: imx51-babbage: fix esdhc cd/wp properties

    commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream.

    The binding doc and dts use properties "fsl,{cd,wp}-internal" while
    esdhc driver uses "fsl,{cd,wp}-controller".  Fix binding doc and dts
    to get them match driver code.

    Reported-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Acked-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 296397b9d43d5dfd2de45605fe4e3ddb99e06585
Author: Manoj Chourasia <mchourasia@nvidia.com>
Date:   Mon Jul 22 15:33:13 2013 +0530

    HID: hidraw: correctly deallocate memory on device disconnect

    commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

    This changes puts the commit 4fe9f8e203f back in place
    with the fixes for slab corruption because of the commit.

    When a device is unplugged, wait for all processes that
    have opened the device to close before deallocating the device.

    This commit was solving kernel crash because of the corruption in
    rb tree of vmalloc. The rootcause was the device data pointer was
    geting excessed after the memory associated with hidraw was freed.

    The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
    first and then calling delete operation on the list associated with
    that hidraw leading to slab corruption.

    Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
    Tested-by: Peter Wu <lekensteyn@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02a2efebc53168d09f243c308d65457e2ac97ec0
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Mar 18 15:50:10 2013 +0100

    HID: usbhid: fix build problem

    commit 570637dc8eeb2faba06228d497ff40bb019bcc93 upstream.

    Fix build problem caused by typo introduced by 620ae90ed8
    ("HID: usbhid: quirk for MSI GX680R led panel").

    Reported-by: fengguang.wu@intel.com
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc4bf0089f8eeab4356c3681c46424523137b813
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Mon Mar 18 09:47:02 2013 -0400

    HID: usbhid: quirk for MSI GX680R led panel

    commit 620ae90ed8ca8b6e40cb9e10279b4f5ef9f0ab81 upstream.

    This keyboard backlight device causes a 10 second delay to boot.  Add it
    to the quirk list with HID_QUIRK_NO_INIT_REPORTS.

    This fixes Red Hat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=907221

    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb1f5bdebc120a23c5ac53bd5e13dd721a5f02e
Author: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Date:   Tue Jan 22 15:20:38 2013 +0900

    HID: clean up quirk for Sony RF receivers

    commit 99d249021abd4341771523ed8dd7946276103432 upstream.

    Document what the fix-up is does and make it more robust by ensuring
    that it is only applied to the USB interface that corresponds to the
    mouse (sony_report_fixup() is called once per interface during probing).

    Cc: linux-input@vger.kernel.org
    Cc: linux-usb@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c3349c95ea4445a5051966b12df53930534d38d
Author: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Date:   Tue Jan 15 19:40:48 2013 +0900

    HID: add support for Sony RF receiver with USB product id 0x0374

    commit a464918419f94a0043d2f549d6defb4c3f69f68a upstream.

    Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
    a RF receiver, multi-interface USB device 054c:0374, that is used to connect
    a wireless keyboard and a wireless mouse.

    The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
    seem to be generating any pointer events. The problem is that the mouse pointer
    is wrongly declared as a constant non-data variable in the report descriptor
    (see lsusb and usbhid-dump output below), with the consequence that it is
    ignored by the HID code.

    Add this device to the have-special-driver list and fix up the report
    descriptor in the Sony-specific driver which happens to already have a fixup
    for a similar firmware bug.

    # lsusb -vd 054C:0374
    Bus 003 Device 002: ID 054c:0374 Sony Corp.
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0         8
      idVendor           0x054c Sony Corp.
      idProduct          0x0374
      iSerial                 0
    [...]
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass         3 Human Interface Device
          bInterfaceSubClass      1 Boot Interface Subclass
          bInterfaceProtocol      2 Mouse
          iInterface              2 RF Receiver
    [...]
              Report Descriptor: (length is 100)
    [...]
                Item(Global): Usage Page, data= [ 0x01 ] 1
                                Generic Desktop Controls
                Item(Local ): Usage, data= [ 0x30 ] 48
                                Direction-X
                Item(Local ): Usage, data= [ 0x31 ] 49
                                Direction-Y
                Item(Global): Report Count, data= [ 0x02 ] 2
                Item(Global): Report Size, data= [ 0x08 ] 8
                Item(Global): Logical Minimum, data= [ 0x81 ] 129
                Item(Global): Logical Maximum, data= [ 0x7f ] 127
                Item(Main  ): Input, data= [ 0x07 ] 7
                                Constant Variable Relative No_Wrap Linear
                                Preferred_State No_Null_Position Non_Volatile Bitfield

    # usbhid-dump
    003:002:001:DESCRIPTOR         1357910009.758544
     05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01
     A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01
     81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02
     75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00
     45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85
     01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06
     C0 C0 C0 C0

    Cc: linux-input@vger.kernel.org
    Cc: linux-usb@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 180f7cc29a34644dd3254ae773a9c6808b7bb0a9
Author: Alexey Kaminsky <me@akaminsky.net>
Date:   Mon Apr 23 18:02:18 2012 +0200

    HID: apple: Add Apple wireless keyboard 2011 ANSI PID

    commit 0a97e1e9f9a6765e6243030ac42b04694f3f3647 upstream.

    Signed-off-by: Alexey Kaminsky <me@akaminsky.net>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: add the device ID to hid-ids.h]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0c4ced0736d0c79282b78993153741177ef8414
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Aug 15 23:31:45 2012 +0400

    HID: hidraw: improve error handling in hidraw_init()

    commit bcb4a75bde3821cecb17a71d287abfd6ef9bd68d upstream.

    Several improvements in error handling:
    - do not report success if alloc_chrdev_region() failed
    - check for error code of cdev_add()
    - use unregister_chrdev_region() instead of unregister_chrdev()
      if class_create() failed

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b0bbae734e5eae7f879810ada5c964ff072f204
Author: Matthieu CASTET <matthieu.castet@parrot.com>
Date:   Thu Jun 28 16:51:56 2012 +0200

    HID: hidraw: fix list->buffer memleak

    commit 4c7b417ecb756e85dfc955b0e7a04fd45585533e upstream.

    If we don't read fast enough hidraw device, hidraw_report_event
    will cycle and we will leak list->buffer.
    Also list->buffer are not free on release.
    After this patch, kmemleak report nothing.

    Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2f7288dfd21d4cbb88ca879b1fe467b0d6e9942
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Apr 30 10:39:17 2012 +0200

    HID: fix return value of hidraw_report_event() when !CONFIG_HIDRAW

    commit d6d7c873529abd622897cad5e36f1fd7d82f5110 upstream.

    Commit b6787242f327 ("HID: hidraw: add proper error handling to raw event
    reporting") forgot to update the static inline version of
    hidraw_report_event() for the case when CONFIG_HIDRAW is unset. Fix that
    up.

    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eab98e2e636da1a8ac9655cc214223352c25f7fd
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri Apr 27 00:56:08 2012 +0200

    HID: hidraw: add proper error handling to raw event reporting

    commit b6787242f32700377d3da3b8d788ab3928bab849 upstream.

    If kmemdup() in hidraw_report_event() fails, we are not propagating
    this fact properly.

    Let hidraw_report_event() and hid_report_raw_event() return an error
    value to the caller.

    Reported-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e55351c6ff8abccc6dee0432eeb282879e49e5a5
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Sep 11 21:56:58 2013 +0200

    HID: multitouch: validate indexes details

    commit 8821f5dc187bdf16cfb32ef5aa8c3035273fa79a upstream.

    When working on report indexes, always validate that they are in bounds.
    Without this, a HID device could report a malicious feature report that
    could trick the driver into a heap overflow:

    [  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
    ...
    [  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    Note that we need to change the indexes from s8 to s16 as they can
    be between -1 and 255.

    CVE-2013-2897

    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: mt_device::{cc,cc_value,inputmode}_index do not
     exist and the corresponding indices do not need to be validated.
     mt_device::maxcontact_report_id does not exist either.  So all we need
     to do is to widen mt_device::inputmode.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yjw: Backport to 3.4: maxcontact_report_id exists,
     need to be validated]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c540a2bc58ffbcb0e6bd531eefaa9b20bf91d5ea
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Sep 11 21:56:57 2013 +0200

    HID: validate feature and input report details

    commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.

    When dealing with usage_index, be sure to properly use unsigned instead of
    int to avoid overflows.

    When working on report fields, always validate that their report_counts are
    in bounds.
    Without this, a HID device could report a malicious feature report that
    could trick the driver into a heap overflow:

    [  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
    ...
    [  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2897

    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2:
     - Drop inapplicable changes to hid_usage::usage_index initialisation and
       to hid_report_raw_event()
     - Adjust context in report_features()
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yijingwang: Backported to 3.4: context adjust]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7c0d8aee1f1e715827961846f10d754ec950474
Author: Nicholas Santos <nicholas.santos@gmail.com>
Date:   Fri Dec 28 22:07:02 2012 -0500

    HID: usbhid: quirk for Formosa IR receiver

    commit 320cde19a4e8f122b19d2df7a5c00636e11ca3fb upstream.

    Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver
    [IR605A/Q] to hid-ids.h and hid-quirks.c.  This IR receiver causes about a 10
    second timeout when the usbhid driver attempts to initialze the device.  Adding
    this device to the quirks list with HID_QUIRK_NO_INIT_REPORTS removes the
    delay.

    Signed-off-by: Nicholas Santos <nicholas.santos@gmail.com>
    [jkosina@suse.cz: fix ordering]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Nicholas Santos <nicholas.santos@gmail.com>
    [jkosina@suse.cz: fix ordering]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yjw: Backported to 3.4: adjust context]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72c6ff06bdf43f0ad2c59fa3dcf918078af23709
Author: Marek Vasut <marex@denx.de>
Date:   Sun Aug 5 23:57:15 2012 +0200

    HID: add quirk for Freescale i.MX28 ROM recovery

    commit 2843b673d03421e0e73cf061820d1db328f7c8eb upstream.

    The USB recovery mode present in i.MX28 ROM emulates USB HID.
    It needs this quirk to behave properly.

    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Chen Peter <B29397@freescale.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    [jkosina@suse.cz: fix alphabetical ordering]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [yjw: Backported to 3.4: adjust context]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe7d26183b85b534f190a14adf02d6baa146dde0
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>
    Cc: Daniel Kiper <daniel.kiper@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa7919d40215547b7f74dfc5f3a75ca552a4109a
Author: Paul Moore <pmoore@redhat.com>
Date:   Wed Mar 19 16:46:18 2014 -0400

    selinux: correctly label /proc inodes in use before the policy is loaded

    commit f64410ec665479d7b4b77b7519e814253ed0f686 upstream.

    This patch is based on an earlier patch by Eric Paris, he describes
    the problem below:

      "If an inode is accessed before policy load it will get placed on a
       list of inodes to be initialized after policy load.  After policy
       load we call inode_doinit() which calls inode_doinit_with_dentry()
       on all inodes accessed before policy load.  In the case of inodes
       in procfs that means we'll end up at the bottom where it does:

         /* Default to the fs superblock SID. */
         isec->sid = sbsec->sid;

         if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
                 if (opt_dentry) {
                         isec->sclass = inode_mode_to_security_class(...)
                         rc = selinux_proc_get_sid(opt_dentry,
                                                   isec->sclass,
                                                   &sid);
                         if (rc)
                                 goto out_unlock;
                         isec->sid = sid;
                 }
         }

       Since opt_dentry is null, we'll never call selinux_proc_get_sid()
       and will leave the inode labeled with the label on the superblock.
       I believe a fix would be to mimic the behavior of xattrs.  Look
       for an alias of the inode.  If it can't be found, just leave the
       inode uninitialized (and pick it up later) if it can be found, we
       should be able to call selinux_proc_get_sid() ..."

    On a system exhibiting this problem, you will notice a lot of files in
    /proc with the generic "proc_t" type (at least the ones that were
    accessed early in the boot), for example:

       # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
       system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax

    However, with this patch in place we see the expected result:

       # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
       system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax

    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dda2852f907934c746fdd364783eff3edcdcdb4
Author: George Spelvin <linux@horizon.com>
Date:   Tue Feb 12 02:27:20 2013 -0500

    pps: Fix a use-after free bug when unregistering a source.

    commit d953e0e837e65ecc1ddaa4f9560f7925878a0de6 upstream.

    Remove the cdev from the system (with cdev_del) *before* deallocating it
    (in pps_device_destruct, called via kobject_put from device_destroy).

    Also prevent deallocating a device with open file handles.

    A better long-term fix is probably to remove the cdev from the pps_device
    entirely, and instead have all devices reference one global cdev.  Then
    the deallocation ordering becomes simpler.

    But that's more complex and invasive change, so we leave that
    for later.

    Signed-off-by: George Spelvin <linux@horizon.com>
    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 171e3707584954b8b9ac96fe66860db27fdb39b8
Author: George Spelvin <linux@horizon.com>
Date:   Sun Feb 10 04:41:56 2013 -0500

    pps: Use pps_lookup_dev to reduce ldisc coupling

    commit 03a7ffe4e542310838bac70ef85acc17536b6d7c upstream.

    Now that N_TTY uses tty->disc_data for its private data,
    'subclass' ldiscs cannot use ->disc_data for their own private data.
    (This is a regression is v3.8-rc1)

    Use pps_lookup_dev to associate the tty with the pps source instead.

    This fixes a crashing regression in 3.8-rc1.

    Signed-off-by: George Spelvin <linux@horizon.com>
    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06b63501fd93c27703cb34bea7f842ca4a27b474
Author: George Spelvin <linux@horizon.com>
Date:   Sun Feb 10 04:08:32 2013 -0500

    pps: Add pps_lookup_dev() function

    commit 513b032c98b4b9414aa4e9b4a315cb1bf0380101 upstream.

    The PPS serial line discipline wants to attach a PPS device to a tty
    without changing the tty code to add a struct pps_device * pointer.

    Since the number of PPS devices in a typical system is generally very low
    (n=1 is by far the most common), it's practical to search the entire list
    of allocated pps devices.  (We capture the timestamp before the lookup,
    so the timing isn't affected.)

    It is a bit ugly that this function, which is part of the in-kernel
    PPS API, has to be in pps.c as opposed to kapi,c, but that's not
    something that affects users.

    Signed-off-by: George Spelvin <linux@horizon.com>
    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c4b23693d7dd044b7b861404a75cf1679552ac3
Author: Philipp Reisner <philipp.reisner@linbit.com>
Date:   Wed Jul 20 14:59:37 2011 +0200

    idr: idr_for_each_entry() macro

    commit 9749f30f1a387070e6e8351f35aeb829eacc3ab6 upstream.

    Inspired by the list_for_each_entry() macro

    Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3be7020ad97b8941e9985e85b2bd604c0e8221
Author: Mathias Krause <minipli@googlemail.com>
Date:   Tue Nov 12 15:11:47 2013 -0800

    ipc, msg: fix message length check for negative values

    commit 4e9b45a19241354daec281d7a785739829b52359 upstream.

    On 64 bit systems the test for negative message sizes is bogus as the
    size, which may be positive when evaluated as a long, will get truncated
    to an int when passed to load_msg().  So a long might very well contain a
    positive value but when truncated to an int it would become negative.

    That in combination with a small negative value of msg_ctlmax (which will
    be promoted to an unsigned type for the comparison against msgsz, making
    it a big positive value and therefore make it pass the check) will lead to
    two problems: 1/ The kmalloc() call in alloc_msg() will allocate a too
    small buffer as the addition of alen is effectively a subtraction.  2/ The
    copy_from_user() call in load_msg() will first overflow the buffer with
    userland data and then, when the userland access generates an access
    violation, the fixup handler copy_user_handle_tail() will try to fill the
    remainder with zeros -- roughly 4GB.  That almost instantly results in a
    system crash or reset.

      ,-[ Reproducer (needs to be run as root) ]--
      | #include <sys/stat.h>
      | #include <sys/msg.h>
      | #include <unistd.h>
      | #include <fcntl.h>
      |
      | int main(void) {
      |     long msg = 1;
      |     int fd;
      |
      |     fd = open("/proc/sys/kernel/msgmax", O_WRONLY);
      |     write(fd, "-1", 2);
      |     close(fd);
      |
      |     msgsnd(0, &msg, 0xfffffff0, IPC_NOWAIT);
      |
      |     return 0;
      | }
      '---

    Fix the issue by preventing msgsz from getting truncated by consistently
    using size_t for the message length.  This way the size checks in
    do_msgsnd() could still be passed with a negative value for msg_ctlmax but
    we would fail on the buffer allocation in that case and error out.

    Also change the type of m_ts from int to size_t to avoid similar nastiness
    in other code paths -- it is used in similar constructs, i.e.  signed vs.
    unsigned checks.  It should never become negative under normal
    circumstances, though.

    Setting msg_ctlmax to a negative value is an odd configuration and should
    be prevented.  As that might break existing userland, it will be handled
    in a separate commit so it could easily be reverted and reworked without
    reintroducing the above described bug.

    Hardening mechanisms for user copy operations would have catched that bug
    early -- e.g.  checking slab object sizes on user copy operations as the
    usercopy feature of the PaX patch does.  Or, for that matter, detect the
    long vs.  int sign change due to truncation, as the size overflow plugin
    of the very same patch does.

    [akpm@linux-foundation.org: fix i386 min() warnings]
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Pax Team <pageexec@freemail.hu>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Brad Spengler <spender@grsecurity.net>
    Cc: Manfred Spraul <manfred@colorfullife.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
     - Drop changes to alloc_msg() and copy_msg(), which don't exist]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc9e8eadf3215a4e7bed0447437fbe053aa160b4
Author: Ingo Molnar <mingo@kernel.org>
Date:   Thu Oct 10 10:16:30 2013 +0200

    compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

    commit 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

    Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
    a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
    constructs, as outlined here:

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670

    Implement a workaround suggested by Jakub Jelinek.

    Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Suggested-by: Jakub Jelinek <jakub@redhat.com>
    Reviewed-by: Richard Henderson <rth@twiddle.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [hq: Backported to 3.4: Adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5c634374440ad4d8a904b1514741e1ed2a2e228
Author: Daniel Santos <daniel.santos@pobox.com>
Date:   Thu Feb 21 16:41:39 2013 -0800

    compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

    commit 3f3f8d2f48acfd8ed3b8e6b7377935da57b27b16 upstream.

    Throughout compiler*.h, many version checks are made.  These can be
    simplified by using the macro that gcc's documentation recommends.
    However, my primary reason for adding this is that I need bug-check
    macros that are enabled at certain gcc versions and it's cleaner to use
    this macro than the tradition method:

      #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

    If you add patch level, it gets this ugly:

      #if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
          __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

    As opposed to:

      #if GCC_VERSION >= 40201

    While having separate headers for gcc 3 & 4 eliminates some of this
    verbosity, they can still be cleaned up by this.

    See also:

      http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

    Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
    Acked-by: Borislav Petkov <bp@alien8.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 377922d992158dd7d0d792ee2a8f242d60d709e2
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Aug 28 17:33:37 2013 -0400

    workqueue: cond_resched() after processing each work item

    commit b22ce2785d97423846206cceec4efee0c4afd980 upstream.

    If !PREEMPT, a kworker running work items back to back can hog CPU.
    This becomes dangerous when a self-requeueing work item which is
    waiting for something to happen races against stop_machine.  Such
    self-requeueing work item would requeue itself indefinitely hogging
    the kworker and CPU it's running on while stop_machine would wait for
    that CPU to enter stop_machine while preventing anything else from
    happening on all other CPUs.  The two would deadlock.

    Jamie Liu reports that this deadlock scenario exists around
    scsi_requeue_run_queue() and libata port multiplier support, where one
    port may exclude command processing from other ports.  With the right
    timing, scsi_requeue_run_queue() can end up requeueing itself trying
    to execute an IO which is asked to be retried while another device has
    an exclusive access, which in turn can't make forward progress due to
    stop_machine.

    Fix it by invoking cond_resched() after executing each work item.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Jamie Liu <jamieliu@google.com>
    References: http://thread.gmane.org/gmane.linux.kernel/1552567
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 683ce42f313d322b9d4f1ffb0588f4c096b2e31d
Author: Bu, Yitian <ybu@qti.qualcomm.com>
Date:   Mon Feb 18 12:53:37 2013 +0000

    printk: Fix rq->lock vs logbuf_lock unlock lock inversion

    commit dbda92d16f8655044e082930e4e9d244b87fde77 upstream.

    commit 07354eb1a74d1 ("locking printk: Annotate logbuf_lock as raw")
    reintroduced a lock inversion problem which was fixed in commit
    0b5e1c5255 ("printk: Release console_sem after logbuf_lock"). This
    happened probably when fixing up patch rejects.

    Restore the ordering and unlock logbuf_lock before releasing
    console_sem.

    Signed-off-by: ybu <ybu@qti.qualcomm.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/E807E903FE6CBE4D95E420FBFCC273B827413C@nasanexd01h.na.qualcomm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 123192b5b5caff25420363e9a63e1ed0378b3b5c
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Wed Jun 12 14:04:46 2013 -0700

    audit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE

    commit f000cfdde5de4fc15dead5ccf524359c07eadf2b upstream.

    audit_log_start() does wait_for_auditd() in a loop until
    audit_backlog_wait_time passes or audit_skb_queue has a room.

    If signal_pending() is true this becomes a busy-wait loop, schedule() in
    TASK_INTERRUPTIBLE won't block.

    Thanks to Guy for fully investigating and explaining the problem.

    (akpm: that'll cause the system to lock up on a non-preemptible
    uniprocessor kernel)

    (Guy: "Our customer was in fact running a uniprocessor machine, and they
    reported a system hang.")

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Guy Streeter <streeter@redhat.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    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, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfa7687234a1fd63c87ab88420378382ae7dd27c
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Feb 27 17:05:02 2013 -0800

    idr: fix top layer handling

    commit 326cf0f0f308933c10236280a322031f0097205d upstream.

    Most functions in idr fail to deal with the high bits when the idr
    tree grows to the maximum height.

    * idr_get_empty_slot() stops growing idr tree once the depth reaches
      MAX_IDR_LEVEL - 1, which is one depth shallower than necessary to
      cover the whole range.  The function doesn't even notice that it
      didn't grow the tree enough and ends up allocating the wrong ID
      given sufficiently high @starting_id.

      For example, on 64 bit, if the starting id is 0x7fffff01,
      idr_get_empty_slot() will grow the tree 5 layer deep, which only
      covers the 30 bits and then proceed to allocate as if the bit 30
      wasn't specified.  It ends up allocating 0x3fffff01 without the bit
      30 but still returns 0x7fffff01.

    * __idr_remove_all() will not remove anything if the tree is fully
      grown.

    * idr_find() can't find anything if the tree is fully grown.

    * idr_for_each() and idr_get_next() can't iterate anything if the tree
      is fully grown.

    Fix it by introducing idr_max() which returns the maximum possible ID
    given the depth of tree and replacing the id limit checks in all
    affected places.

    As the idr_layer pointer array pa[] needs to be 1 larger than the
    maximum depth, enlarge pa[] arrays by one.

    While this plugs the discovered issues, the whole code base is
    horrible and in desparate need of rewrite.  It's fragile like hell,

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    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
     - s/MAX_IDR_LEVEL/MAX_LEVEL/; s/MAX_IDR_SHIFT/MAX_ID_SHIFT/
     - Drop change to idr_alloc()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4a0e9d817384541200b2d62a4baaf0a8748536a
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Mon Dec 17 16:03:17 2012 -0800

    proc: pid/status: show all supplementary groups

    commit 8d238027b87e654be552eabdf492042a34c5c300 upstream.

    We display a list of supplementary group for each process in
    /proc/<pid>/status.  However, we show only the first 32 groups, not all of
    them.

    Although this is rare, but sometimes processes do have more than 32
    supplementary groups, and this kernel limitation breaks user-space apps
    that rely on the group list in /proc/<pid>/status.

    Number 32 comes from the internal NGROUPS_SMALL macro which defines the
    length for the internal kernel "small" groups buffer.  There is no
    apparent reason to limit to this value.

    This patch removes the 32 groups printing limit.

    The Linux kernel limits the amount of supplementary groups by NGROUPS_MAX,
    which is currently set to 65536.  And this is the maximum count of groups
    we may possibly print.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf659d239330e82654a59e67309ffaba7baa10da
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 3 11:59:21 2014 -0700

    Linux 3.4.86

commit 7e3120b78898afb3a27a70c8fe995c16ef58a44f
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Mon Jan 6 00:57:54 2014 +0100

    netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages

    commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.

    Some occurences in the netfilter tree use skb_header_pointer() in
    the following way ...

      struct dccp_hdr _dh, *dh;
      ...
      skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);

    ... where dh itself is a pointer that is being passed as the copy
    buffer. Instead, we need to use &_dh as the forth argument so that
    we're copying the data into an actual buffer that sits on the stack.

    Currently, we probably could overwrite memory on the stack (e.g.
    with a possibly mal-formed DCCP packet), but unintentionally, as
    we only want the buffer to be placed into _dh variable.

    Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 062123a38c6efa8c1f6b330b72bbaff1d933d4a9
Author: Artem Fetishev <artem_fetishev@epam.com>
Date:   Fri Mar 28 13:33:39 2014 -0700

    x86: fix boot on uniprocessor systems

    commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream.

    On x86 uniprocessor systems topology_physical_package_id() returns -1
    which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized
    which leads to GPF in rapl_pmu_init().

    See arch/x86/kernel/cpu/perf_event_intel_rapl.c.

    It turns out that physical_package_id and core_id can actually be
    retreived for uniprocessor systems too.  Enabling them also fixes
    rapl_pmu code.

    Signed-off-by: Artem Fetishev <artem_fetishev@epam.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92c98b82f6318ab43fec19f1ef98ea417477b491
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Mar 28 01:01:38 2014 -0700

    Input: synaptics - add manual min/max quirk for ThinkPad X240

    commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

    This extends Benjamin Tissoires manual min/max quirk table with support for
    the ThinkPad X240.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcb0a40ae351d8c90facd64488b82c920e739842
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Mar 28 00:43:00 2014 -0700

    Input: synaptics - add manual min/max quirk

    commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

    The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
    However, these new Synaptics devices report bad axis ranges.
    Under Windows, it is not a problem because the Windows driver uses RMI4
    over SMBus to talk to the device. Under Linux, we are using the PS/2
    fallback interface and it occurs the reported ranges are wrong.

    Of course, it would be too easy to have only one range for the whole
    series, each touchpad seems to be calibrated in a different way.

    We can not use SMBus to get the actual range because I suspect the firmware
    will switch into the SMBus mode and stop talking through PS/2 (this is the
    case for hybrid HID over I2C / PS/2 Synaptics touchpads).

    So as a temporary solution (until RMI4 land into upstream), start a new
    list of quirks with the min/max manually set.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21f11c510c1890fd79eaedd3d9a034999f68c857
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Mar 30 10:20:01 2014 -0400

    ext4: atomically set inode->i_flags in ext4_set_inode_flags()

    commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.

    Use cmpxchg() to atomically set i_flags instead of clearing out the
    S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
    EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
    where an immutable file has the immutable flag cleared for a brief
    window of time.

    Reported-by: John Sullivan <jsrhbz@kanargh.force9.co.uk>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8eda86ca13693ba256f460f79949c7dd871cb798
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Wed Jan 2 02:37:40 2013 +0100

    staging: speakup: Prefix externally-visible symbols

    commit ca2beaf84d9678c12b17d92623f0e90829d6ca13 upstream.

    This prefixes all externally-visible symbols of speakup with "spk_".

    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Cc: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2620d2989b15b12b5d27c640ae72e9586a34b678
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Mar 30 21:40:45 2014 -0700

    Linux 3.4.85

commit ec81647d322298ca563b30ffbb16d74405c64e47
Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Date:   Wed Mar 26 14:12:19 2014 +0400

    ipc/msg: fix race around refcount

    [fixed differently in 6062a8dc0517bce23e3c2f7d2fea5e22411269a3 upstream.]

    In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int.
    There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under
    msq->q_perm->lock and RCU, while freequeue() calls it while it holds only
    'rw_mutex', so there is no sinchronization between them. Two function
    decrements '2' non-atomically, they both can get '0' as result.

    do_msgsnd()					freequeue()

    msq = msg_lock_check(ns, msqid);
    ...
    ipc_rcu_getref(msq);
    msg_unlock(msq);
    schedule();
    						(caller locks spinlock)
    						expunge_all(msq, -EIDRM);
    						ss_wakeup(&msq->q_senders, 1);
    						msg_rmid(ns, msq);
    						msg_unlock(msq);
    ipc_lock_by_ptr(&msq->q_perm);
    ipc_rcu_putref(msq);				ipc_rcu_putref(msq);
    < both may get get --(...)->refcount == 0 >

    This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue.
    ( RCU protects memory for spin_unlock() )

    Similar bugs might be in other users of ipc_rcu_putref().

    In the mainline this has been fixed in v3.10 indirectly in commmit
    6062a8dc0517bce23e3c2f7d2fea5e22411269a3
    ("ipc,sem: fine grained locking for semtimedop") by Rik van Riel.
    That commit optimized locking and converted refcount into atomic.

    I'm not sure that anybody should care about this bug: it's very-very unlikely
    and no longer exists in actual mainline. I've found this just by looking into
    the code, probably this never happens in real life.

    Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>

commit 7712cd2302be3ad08099b296f93d1bc7f8a41981
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 17 15:38:12 2014 -0800

    xhci: Fix resume issues on Renesas chips in Samsung laptops

    commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.

    Don Zickus <dzickus@redhat.com> writes:

    Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
    Those ports did not resume correctly (the driver would timeout communicating
    and fail).  This led to frustration as suspend/resume is a common use for
    laptops.

    Poking around, I applied the reset on resume quirk to this chipset and the
    resume started working.  Reloading the xhci_hcd module had been the temporary
    workaround.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Don Zickus <dzickus@redhat.com>
    Tested-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 737c8449761781485c68410375bb93803757cc2a
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Fri Jan 3 17:00:51 2014 -0200

    KVM: VMX: fix use after free of vmx->loaded_vmcs

    commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

    After free_loaded_vmcs executes, the "loaded_vmcs" structure
    is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
    Subsequent free_loaded_vmcs then attempts to manipulate
    vmx->loaded_vmcs.

    Switch the order to avoid the problem.

    https://bugzilla.redhat.com/show_bug.cgi?id=1047892

    Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4de1169cae3fe750cc31d5b82a6a1fe86207908a
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Thu Dec 19 15:28:51 2013 -0200

    KVM: MMU: handle invalid root_hpa at __direct_map

    commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

    It is possible for __direct_map to be called on invalid root_hpa
    (-1), two examples:

    1) try_async_pf -> can_do_async_pf
        -> vmx_interrupt_allowed -> nested_vmx_vmexit
    2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit

    Then to load_vmcs12_host_state and kvm_mmu_reset_context.

    Check for this possibility, let fault exception be regenerated.

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916

    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86a44ad4e2c279d447b5212e1d266bca145f21c1
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 16 07:09:25 2013 -0800

    Input: elantech - improve clickpad detection

    commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.

    The current assumption in the elantech driver that hw version 3 touchpads
    are never clickpads and hw version 4 touchpads are always clickpads is
    wrong.

    There are several bug reports for this, ie:
    https://bugzilla.redhat.com/show_bug.cgi?id=1030802
    http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux

    I've spend a couple of hours wading through various bugzillas, launchpads
    and forum posts to create a list of fw-versions and capabilities for
    different laptop models to find a good method to differentiate between
    clickpads and versions with separate hardware buttons.

    Which shows that a device being a clickpad is reliable indicated by bit 12
    being set in the fw_version. I've included the gathered list inside the
    driver, so that we've this info at hand if we need to revisit this later.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94b6628ec0fdcaff5fe7ca367c3df0f69933134e
Author: Rob Herring <rob.herring@calxeda.com>
Date:   Sat Aug 17 20:12:57 2013 -0500

    ARM: move outer_cache declaration out of ifdef

    commit 0b53c11d533a8f6688d73fad0baf67dd08ec1b90 upstream.

    Move the outer_cache declaration of the CONFIG_OUTER_CACHE ifdef so that
    outer_cache can be used inside IS_ENABLED condition.

    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e52d25637bb06bafcc0b10f2655a91e6cd14e008
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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc4303192cf1741e10cb9b807284962d04fdc53a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jan 13 22:05:23 2014 +0300

    p54: clamp properly instead of just truncating

    commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.

    The call to clamp_t() first truncates the variable signed 8 bit and as a
    result, the actual clamp is a no-op.

    Fixes: 0d78156eef1d ('p54: improve site survey')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea49a5a3aadd51b24f158885e3a7c0b093ba934c
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 5 14:37:35 2013 +0000

    deb-pkg: Fix cross-building linux-headers package

    commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

    builddeb generates a control file that says the linux-headers package
    can only be built for the build system primary architecture.  This
    breaks cross-building configurations.  We should use $debarch for this
    instead.

    Since $debarch is not yet set when generating the control file, set
    Architecture: any and use control file variables to fill in the
    description.

    Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
    Reported-and-tested-by: "Niew, Sh." <shniew@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ca22b7f3b6311bd9c33f46b00bd72045d7cd5d0
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Mon Mar 10 15:56:51 2014 -0700

    x86: bpf_jit: support negative offsets

    commit fdfaf64e75397567257e1051931f9a3377360665 upstream.

    Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
    but it couldn't be working, since at the time of the execution
    of LD+ABS or LD+IND instructions via call into
    bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
    had junk value instead of access size in bytes (1 or 2 or 4).

    Store size into %edx instead of %ecx (what original commit intended to do)

    Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Cc: Jan Seiffert <kaffeemonster@googlemail.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fc91fca4a56dee92a88d81de745d75e5ee04c2a
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Mar 25 17:28:22 2014 +0000

    iwlwifi: Complete backport of "iwlwifi: always copy first 16 bytes of commands"

    Linux 3.4.83 included an incomplete backport of commit
    8a964f44e01ad3bbc208c3e80d931ba91b9ea786 ('iwlwifi: always copy first
    16 bytes of commands') which causes a regression for this driver.
    This is the missing piece.

    Reported-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Cc: Andres Bertens <abertensu@yahoo.com>
    Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7a70a81761a265f0aaac6e0349d56c688f9c83b3
Author: Josh Durgin <josh.durgin@inktank.com>
Date:   Tue Dec 10 09:35:13 2013 -0800

    libceph: resend all writes after the osdmap loses the full flag

    commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.

    With the current full handling, there is a race between osds and
    clients getting the first map marked full. If the osd wins, it will
    return -ENOSPC to any writes, but the client may already have writes
    in flight. This results in the client getting the error and
    propagating it up the stack. For rbd, the block layer turns this into
    EIO, which can cause corruption in filesystems above it.

    To avoid this race, osds are being changed to drop writes that came
    from clients with an osdmap older than the last osdmap marked full.
    In order for this to work, clients must resend all writes after they
    encounter a full -> not full transition in the osdmap. osds will wait
    for an updated map instead of processing a request from a client with
    a newer map, so resent writes will not be dropped by the osd unless
    there is another not full -> full transition.

    This approach requires both osds and clients to be fixed to avoid the
    race. Old clients talking to osds with this fix may hang instead of
    returning EIO and potentially corrupting an fs. New clients talking to
    old osds have the same behavior as before if they encounter this race.

    Fixes: http://tracker.ceph.com/issues/6938

    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 381c48e074c41b331c97545023167a48ac1e2d2e
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Wed Mar 19 12:59:39 2014 +0000

    ALSA: compress: Pass through return value of open ops callback

    commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream.

    The snd_compr_open function would always return 0 even if the compressed
    ops open function failed, obviously this is incorrect. Looks like this
    was introduced by a small typo in:

    commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85
    ALSA: Add a reference counter to card instance

    This patch returns the value from the compressed op as it should.

    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80ba706a3f5c6e1624bb3172be027617804662b3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Mar 23 21:38:33 2014 -0700

    Linux 3.4.84

commit 64df581dc15bf8e38af21fb0327a3af8c6b6ad2a
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>
    Ruchi Kandoi <kandoiruchi@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4338450259bcc2c8c8bb0b8dd1981a79241f3d9c
Author: Roman Volkov <v1ron@mail.ru>
Date:   Fri Jan 24 16:18:11 2014 +0400

    ALSA: oxygen: modify adjust_dg_dac_routing function

    commit 1f91ecc14deea9461aca93273d78871ec4d98fcd upstream.

    When selecting the audio output destinations (headphones,
    FP headphones, multichannel output), the channel routing
    should be changed depending on what destination selected.
    Also unnecessary I2S channels are digitally muted. This
    function called when the user selects the destination
    in the ALSA mixer.

    Signed-off-by: Roman Volkov <v1ron@mail.ru>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 928c8434fbb8baf8d504fa9eafc4d2d4dbc6158d
Author: Filipe David Borba Manana <fdmanana@gmail.com>
Date:   Sat Feb 8 15:47:46 2014 +0000

    Btrfs: fix data corruption when reading/updating compressed extents

    commit a2aa75e18a21b21952dc6daa9bac7c9f4426f81f upstream.

    When using a mix of compressed file extents and prealloc extents, it
    is possible to fill a page of a file with random, garbage data from
    some unrelated previous use of the page, instead of a sequence of zeroes.

    A simple sequence of steps to get into such case, taken from the test
    case I made for xfstests, is:

       _scratch_mkfs
       _scratch_mount "-o compress-force=lzo"
       $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
       $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
       $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
       $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar

    This results in the following file items in the fs tree:

       item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
           inode generation 6 transid 6 size 542872 block group 0 mode 100600
       item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
           inode ref index 2 namelen 6 name: foobar
       item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
           extent data disk byte 0 nr 0 gen 6
           extent data offset 0 nr 24576 ram 266240
           extent compression 0
       item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
           prealloc data disk byte 12849152 nr 241664 gen 6
           prealloc data offset 0 nr 241664
       item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
           extent data disk byte 12845056 nr 4096 gen 6
           extent data offset 0 nr 20480 ram 20480
           extent compression 2
       item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
           prealloc data disk byte 13090816 nr 405504 gen 6
           prealloc data offset 0 nr 258048

    The on disk extent at offset 266240 (which corresponds to 1 single disk block),
    contains 5 compressed chunks of file data. Each of the first 4 compress 4096
    bytes of file data, while the last one only compresses 3024 bytes of file data.
    Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
    1072 bytes) should always return zeroes (our next extent is a prealloc one).

    The solution here is the compression code path to zero the remaining (untouched)
    bytes of the last page it uncompressed data into, as the information about how
    much space the file data consumes in the last page is not known in the upper layer
    fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
    the remainder of the page but only if it corresponds to the last page of the inode
    and if the inode's size is not a multiple of the page size.

    This would cause not only returning random data on reads, but also permanently
    storing random data when updating parts of the region that should be zeroed.
    For the example above, it means updating a single byte in the region [285648 ; 286720[
    would store that byte correctly but also store random data on disk.

    A test case for xfstests follows soon.

    Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8941925efafe1051fd7d6dc70284b2d9d171590
Author: Ales Novak <alnovak@suse.cz>
Date:   Thu Feb 27 11:03:30 2014 +0100

    SCSI: storvsc: NULL pointer dereference fix

    commit b12bb60d6c350b348a4e1460cd68f97ccae9822e upstream.

    If the initialization of storvsc fails, the storvsc_device_destroy()
    causes NULL pointer dereference.

    storvsc_bus_scan()
      scsi_scan_target()
        __scsi_scan_target()
          scsi_probe_and_add_lun(hostdata=NULL)
            scsi_alloc_sdev(hostdata=NULL)

    	  sdev->hostdata = hostdata

    	  now the host allocation fails

              __scsi_remove_device(sdev)

    	  calls sdev->host->hostt->slave_destroy() ==
    	  storvsc_device_destroy(sdev)
    	    access of sdev->hostdata->request_mempool

    Signed-off-by: Ales Novak <alnovak@suse.cz>
    Signed-off-by: Thomas Abraham <tabraham@suse.com>
    Reviewed-by: Jiri Kosina <jkosina@suse.cz>
    Acked-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 130c01618c3d742249e4d6b28bab43bc76492d97
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d828c6654b9456a26f4bef5dbfb8049c9b0ee2cf
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fbe39e44ed34eb029058ca866f63e30bb66e8b5
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64dbbbc1f8a6c90eb696a3e37fc1b137581ed090
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30f61d676f42d5cc43e1c048aa414a9f111a353f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Mar 6 18:09:52 2014 -0500

    drm/radeon/atom: select the proper number of lanes in transmitter setup

    commit d03874c881a049a50e12f285077ab1f9fc2686e1 upstream.

    We need to check for DVI vs. HDMI when setting up duallink since
    HDMI is single link only.  Fixes 4k modes on newer asics.

    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=75223

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b8250a85c107592adda75f51f4472f3968c714c
Author: Artem Fetishev <artem_fetishev@epam.com>
Date:   Mon Mar 10 15:49:45 2014 -0700

    fs/proc/base.c: fix GPF in /proc/$PID/map_files

    commit 70335abb2689c8cd5df91bf2d95a65649addf50b upstream.

    The expected logic of proc_map_files_get_link() is either to return 0
    and initialize 'path' or return an error and leave 'path' uninitialized.

    By the time dname_to_vma_addr() returns 0 the corresponding vma may have
    already be gone.  In this case the path is not initialized but the
    return value is still 0.  This results in 'general protection fault'
    inside d_path().

    Steps to reproduce:

      CONFIG_CHECKPOINT_RESTORE=y

        fd = open(...);
        while (1) {
            mmap(fd, ...);
            munmap(fd, ...);
        }

      ls -la /proc/$PID/map_files

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991

    Signed-off-by: Artem Fetishev <artem_fetishev@epam.com>
    Signed-off-by: Aleksandr Terekhov <aleksandr_terekhov@epam.com>
    Reported-by: <wiebittewas@gmail.com>
    Acked-by: Pavel Emelyanov <xemul@parallels.com>
    Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8825ef23d5fa7ba24cd776864dcd3f7039d23ecb
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sun Mar 2 22:03:12 2014 -0500

    NFS: Fix a delegation callback race

    commit 755a48a7a4eb05b9c8424e3017d947b2961a60e0 upstream.

    The clean-up in commit 36281caa839f ended up removing a NULL pointer check
    that is needed in order to prevent an Oops in
    nfs_async_inode_return_delegation().

    Reported-by: "Yan, Zheng" <zheng.z.yan@intel.com>
    Link: http://lkml.kernel.org/r/5313E9F6.2020405@intel.com
    Fixes: 36281caa839f (NFSv4: Further clean-ups of delegation stateid validation)
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35064c1140b37107d0c47e2db238724489f15d29
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c2af8075337b8399564ddcb1e5fd2687343524b
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Mar 7 10:19:57 2014 -0500

    firewire: don't use PREPARE_DELAYED_WORK

    commit 70044d71d31d6973665ced5be04ef39ac1c09a48 upstream.

    PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
    and a nasty surprise in terms of reentrancy guarantee as workqueue
    considers work items to be different if they don't have the same work
    function.

    firewire core-device and sbp2 have been been multiplexing work items
    with multiple work functions.  Introduce fw_device_workfn() and
    sbp2_lu_workfn() which invoke fw_device->workfn and
    sbp2_logical_unit->workfn respectively and always use the two
    functions as the work functions and update the users to set the
    ->workfn fields instead of overriding work functions using
    PREPARE_DELAYED_WORK().

    This fixes a variety of possible regressions since a2c1c57be8d9
    "workqueue: consider work function when searching for busy work items"
    due to which fw_workqueue lost its required non-reentrancy property.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Cc: linux1394-devel@lists.sourceforge.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c31bb0181c4bb1af39174da7628c9bf200adc99
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Tue Feb 18 22:25:15 2014 +0100

    firewire: net: fix use after free

    commit 8987583366ae9e03c306c2b7d73bdb952df1d08d upstream.

    Commit 8408dc1c14c1 "firewire: net: use dev_printk API" introduced a
    use-after-free in a failure path.  fwnet_transmit_packet_failed(ptask)
    may free ptask, then the dev_err() call dereferenced it.  The fix is
    straightforward; simply reorder the two calls.

    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39e3a19bbbb8bf1cc85ea971891a4c13f36dce46
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4eaa4afaf2ecbc6f47ab9ab98cad15f35f76f473
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8389656bb627be9232376c697bbf40aedf8fb49d
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c403b39e6b983530c9608410ee321a8c544beaf0
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3343eea04b2649e1e5ba979628083831fe810fb9
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Feb 25 22:41:41 2014 +0100

    ARM: 7991/1: sa1100: fix compile problem on Collie

    commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream.

    Due to a problem in the MFD Kconfig it was not possible to
    compile the UCB battery driver for the Collie SA1100 system,
    in turn making it impossible to compile in the battery driver.
    (See patch "mfd: include all drivers in subsystem menu".)

    After fixing the MFD Kconfig (separate patch) a compile error
    appears in the Collie battery driver due to the <mach/collie.h>
    implicitly requiring <mach/hardware.h> through <linux/gpio.h>
    via <mach/gpio.h> prior to commit
    40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".

    Fix this up by including the required header into
    <mach/collie.h>.

    Cc: Andrea Adami <andrea.adami@gmail.com>
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 755f4a02d6bf3f2abc837c752741f53be6e86187
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7a6392a314778139537b4a1ca1ce69fff1b9ee9
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fafd2e4f1827510e35c19dc6cf950115ef380526
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d817fc2b4c3370cd9c7ab41e0a44cf609fced0
Author: Rob Clark <rclark@redhat.com>
Date:   Wed Mar 12 10:59:37 2014 -0400

    drm/ttm: don't oops if no invalidate_caches()

    commit 9ef7506f7eff3fc42724269f62e30164c141661f upstream.

    A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
    this function.  Yet can end up somehow with an evicted bo:

      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<          (null)>]           (null)
      PGD 16e761067 PUD 16e6cf067 PMD 0
      Oops: 0010 [#1] SMP
      Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom
       sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod
      CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1
      Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009
      task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000
      RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
      RSP: 0018:ffff88016c885ad8  EFLAGS: 00010202
      RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00
      RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0
      R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30
      R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400
      FS:  00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001
       ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700
       ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400
      Call Trace:
       [<ffffffffa0306fae>] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm]
       [<ffffffffa0307669>] ? ttm_bo_mem_space+0x169/0x340 [ttm]
       [<ffffffffa0307bd7>] ttm_bo_move_buffer+0x117/0x130 [ttm]
       [<ffffffff81130001>] ? perf_event_init_context+0x141/0x220
       [<ffffffffa0307cb1>] ttm_bo_validate+0xc1/0x130 [ttm]
       [<ffffffffa04e7377>] mgag200_bo_pin+0x87/0xc0 [mgag200]
       [<ffffffffa04e56c4>] mga_crtc_cursor_set+0x474/0xbb0 [mgag200]
       [<ffffffff811971d2>] ? __mem_cgroup_commit_charge+0x152/0x3b0
       [<ffffffff815c4182>] ? mutex_lock+0x12/0x2f
       [<ffffffffa0201433>] drm_mode_cursor_common+0x123/0x170 [drm]
       [<ffffffffa0205231>] drm_mode_cursor_ioctl+0x41/0x50 [drm]
       [<ffffffffa01f5ca2>] drm_ioctl+0x502/0x630 [drm]
       [<ffffffff815cbab4>] ? __do_page_fault+0x1f4/0x510
       [<ffffffff8101cb68>] ? __restore_xstate_sig+0x218/0x4f0
       [<ffffffff811b4445>] do_vfs_ioctl+0x2e5/0x4d0
       [<ffffffff8124488e>] ? file_has_perm+0x8e/0xa0
       [<ffffffff811b46b1>] SyS_ioctl+0x81/0xa0
       [<ffffffff815d05d9>] system_call_fastpath+0x16/0x1b
      Code:  Bad RIP value.
      RIP  [<          (null)>]           (null)
       RSP <ffff88016c885ad8>
      CR2: 0000000000000000

    Signed-off-by: Rob Clark <rclark@redhat.com>
    Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b63f9c47b4b8ea35ee064dd221b7abedb9b485f2
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fef134e9e8cd6fa80ca1ef8d9506590384b7174
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f9bf2c1cc289dce30b93ec86da2d1a5b2ddfc9a
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a086b2e584346bb975c027173fe52d44d32688e
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d481b10001603afa43c6abad80ca636ebbaa66d6
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c100bd5674adc25cfecbb05deed5b29d54331fc7
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df1f77a475e8738ee22b40bfb0ed11a6ff7f54fd
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8f46d7320e869c8fb2808cf274acb815a648313
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b457de5c3609e650340563add63207497fe5abae
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ebf213bd7a4e864b90a6cc1dcd1871340e7c177
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Mar 11 16:10:41 2014 -0700

    Linux 3.4.83

commit 44868972023cd90495b9468a7227a671b933af36
Author: Emil Goode <emilgoode@gmail.com>
Date:   Thu Feb 13 19:30:39 2014 +0100

    net: asix: add missing flag to struct driver_info

    commit d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.

    The struct driver_info ax88178_info is assigned the function
    asix_rx_fixup_common as it's rx_fixup callback. This means that
    FLAG_MULTI_PACKET must be set as this function is cloning the
    data and calling usbnet_skb_return. Not setting this flag leads
    to usbnet_skb_return beeing called a second time from within
    the rx_process function in the usbnet module.

    Signed-off-by: Emil Goode <emilgoode@gmail.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83c9ae22c6ce75607b47ac5bf90558b70f8192e0
Author: Lucas Stach <dev@lynxeye.de>
Date:   Thu Feb 27 12:51:38 2014 +0100

    net: asix: handle packets crossing URB boundaries

    commit 8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.

    ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
    header may now cross URB boundaries. To handle this we have to introduce
    some state between individual calls to asix_rx_fixup().

    Signed-off-by: Lucas Stach <dev@lynxeye.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [ Emil: backported to 3.4: dropped changes to drivers/net/usb/ax88172a.c ]
    Signed-off-by: Emil Goode <emilgoode@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fbc6832ecdb10f8f8ca71e62fefe9e8dad3dc95
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date:   Thu Feb 27 09:53:03 2014 +0800

    rtlwifi: Fix endian error in extracting packet type

    commit 0c5d63f0ab6728f05ddefa25aff55e31297f95e6 upstream.

    All of the rtlwifi drivers have an error in the routine that tests if
    the data is "special". If it is, the subsequant transmission will be
    at the lowest rate to enhance reliability. The 16-bit quantity is
    big-endian, but was being extracted in native CPU mode. One of the
    effects of this bug is to inhibit association under some conditions
    as the TX rate is too high.

    Based on suggestions by Joe Perches, the entire routine is rewritten.

    One of the local headers contained duplicates of some of the ETH_P_XXX
    definitions. These are deleted.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [wujg: Backported to 3.4:
     - adjust context
     - remove rtlpriv->enter_ps = false
     - use schedule_work(&rtlpriv->works.lps_leave_work)]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79a9ec55b3360d017f617827dec56391296796f6
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Feb 27 09:53:02 2014 +0800

    iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series

    commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream.

    Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Adjust filenames
     - Drop const from struct iwl_cfg]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4:
     - Adjust context
     - Do not drop const from struct iwl_cfg]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 508a6c2dc92db294b33c3506693bd0f92f93d342
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Feb 27 09:53:01 2014 +0800

    iwlwifi: dvm: fix calling ieee80211_chswitch_done() with NULL

    commit 9186a1fd9ed190739423db84bc344d258ef3e3d7 upstream.

    If channel switch is pending and we remove interface we can
    crash like showed below due to passing NULL vif to mac80211:

    BUG: unable to handle kernel paging request at fffffffffffff8cc
    IP: [<ffffffff8130924d>] strnlen+0xd/0x40
    Call Trace:
     [<ffffffff8130ad2e>] string.isra.3+0x3e/0xd0
     [<ffffffff8130bf99>] vsnprintf+0x219/0x640
     [<ffffffff8130c481>] vscnprintf+0x11/0x30
     [<ffffffff81061585>] vprintk_emit+0x115/0x4f0
     [<ffffffff81657bd5>] printk+0x61/0x63
     [<ffffffffa048987f>] ieee80211_chswitch_done+0xaf/0xd0 [mac80211]
     [<ffffffffa04e7b34>] iwl_chswitch_done+0x34/0x40 [iwldvm]
     [<ffffffffa04f83c3>] iwlagn_commit_rxon+0x2a3/0xdc0 [iwldvm]
     [<ffffffffa04ebc50>] ? iwlagn_set_rxon_chain+0x180/0x2c0 [iwldvm]
     [<ffffffffa04e5e76>] iwl_set_mode+0x36/0x40 [iwldvm]
     [<ffffffffa04e5f0d>] iwlagn_mac_remove_interface+0x8d/0x1b0 [iwldvm]
     [<ffffffffa0459b3d>] ieee80211_do_stop+0x29d/0x7f0 [mac80211]

    This is because we nulify ctx->vif in iwlagn_mac_remove_interface()
    before calling some other functions that teardown interface. To fix
    just check ctx->vif on iwl_chswitch_done(). We should not call
    ieee80211_chswitch_done() as channel switch works were already canceled
    by mac80211 in ieee80211_do_stop() -> ieee80211_mgd_stop().

    Resolve:
    https://bugzilla.redhat.com/show_bug.cgi?id=979581

    Reported-by: Lukasz Jagiello <jagiello.lukasz@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: adjust context, filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4: - adjust context]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3fa96782df6057e056ca7d486dfb51ac2788d8d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 27 09:53:00 2014 +0800

    iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth

    commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream.

    The BT_CONFIG command that is sent to the device during
    startup will enable BT coex unless the module parameter
    turns it off, but on devices without Bluetooth this may
    cause problems, as reported in Redhat BZ 885407.

    Fix this by sending the BT_CONFIG command only when the
    device has Bluetooth.

    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    [bwh: Backported to 3.2:
     - Adjust filename
     - s/priv->lib/priv->cfg/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4:
     - s/priv->cfg/priv->shrd->cfg/]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3d330d30e1f9332b97a17b573290c3df6043b13
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 27 09:52:59 2014 +0800

    iwlwifi: always copy first 16 bytes of commands

    commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.

    The FH hardware will always write back to the scratch field
    in commands, even host commands not just TX commands, which
    can overwrite parts of the command. This is problematic if
    the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
    cause calibration issues.

    Address this problem by always putting at least the first
    16 bytes into the buffer we also use for the command header
    and therefore make the DMA engine write back into this.

    For commands that are smaller than 16 bytes also always map
    enough memory for the DMA engine to write back to.

    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Drop the IWL_HCMD_DFL_DUP handling
     - Fix descriptor addresses and lengths for tracepoint, but otherwise
       leave it unchanged]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4: adjust context]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9cc0cd38f5bf87725b196ad7a0bd81aef3b1052
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 27 09:52:58 2014 +0800

    iwlwifi: handle DMA mapping failures

    commit 7c34158231b2eda8dcbd297be2bb1559e69cb433 upstream.

    The RX replenish code doesn't handle DMA mapping failures,
    which will cause issues if there actually is a failure. This
    was reported by Shuah Khan who found a DMA mapping framework
    warning ("device driver failed to check map error").

    Reported-by: Shuah Khan <shuah.khan@hp.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Adjust filename, context, indentation
     - Use bus(trans) instead of trans where necessary
     - Use hw_params(trans).rx_page_order instead of trans_pcie->rx_page_order]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4:
     - Adjust context
     - Use trans instead of bus(trans)
     - Use hw_params(trans).rx_page_order instead of trans_pcie->rx_page_order]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fb10a39a189e1cdca87f7de0f55bc2c6793459e
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Feb 27 09:52:57 2014 +0800

    iwlwifi: don't handle masked interrupt

    commit 25a172655f837bdb032e451f95441bb4acec51bb upstream.

    This can lead to a panic if the driver isn't ready to
    handle them. Since our interrupt line is shared, we can get
    an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks
    that even when the interrupt is being freed).

    If the op_mode has gone away, we musn't call it. To avoid
    this the transport disables the interrupts when the hw is
    stopped and the op_mode is leaving.
    If there is an event that would cause an interrupt the INTA
    register is updated regardless of the enablement of the
    interrupts: even if the interrupts are disabled, the INTA
    will be changed, but the device won't issue an interrupt.
    But the ISR can be called at any time, so we ought ignore
    the value in the INTA otherwise we can call the op_mode
    after it was freed.

    I found this bug when the op_mode_start failed, and called
    iwl_trans_stop_hw(trans, true). Then I played with the
    RFKILL button, and removed the module.
    While removing the module, the IRQ is freed, and the ISR is
    called (CONFIG_DEBUG_SHIRQ enabled). Panic.

    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Pass bus(trans), not trans, to iwl_{read,write}32()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4:
     - adjust context
     - Pass trans to iwl_{read,write}32()}]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 475a227c7153fb9db4fee3e40c6dd6e5ff88af94
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 27 09:52:56 2014 +0800

    iwlwifi: protect SRAM debugfs

    commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream.

    If the device is not started, we can't read its
    SRAM and attempting to do so will cause issues.
    Protect the debugfs read.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [wujg: Backported to 3.4: adjust context]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d396bab5357a3e3efb3b5938d14f8f5c4dfdabfb
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Feb 27 09:52:55 2014 +0800

    iwlwifi: fix flow handler debug code

    commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream.

    iwl_dbgfs_fh_reg_read() can cause crashes and/or
    BUG_ON in slub because the ifdefs are wrong, the
    code in iwl_dump_fh() should use DEBUGFS, not
    DEBUG to protect the buffer writing code.

    Also, while at it, clean up the arguments to the
    function, some code and make it generally safer.

    Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust filenames and context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wujg: Backported to 3.4: adjust context]
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b8411f004e672125b0c7c3e16a2327fd18b259e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:55:57 2013 +0200

    ALSA: asihpi: Fix unlocked snd_pcm_stop() call

    commit 60478295d6876619f8f47f6d1a5c25eaade69ee3 upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 623b30ae4565eb2ee7664f4b6d5e86498185a077
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 18:02:38 2013 +0200

    staging: line6: Fix unlocked snd_pcm_stop() call

    commit 86f0b5b86d142b9323432fef078a6cf0fb5dda74 upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ASoC: s6000: Fix unlocked snd_pcm_stop() call

    commit 61be2b9a18ec70f3cbe3deef7a5f77869c71b5ae upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Acked-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 155b5bf2b52698412a9c2b4dd07c030fe2f48b98
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:59:33 2013 +0200

    ALSA: pxa2xx: Fix unlocked snd_pcm_stop() call

    commit 46f6c1aaf790be9ea3c8ddfc8f235a5f677d08e2 upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Acked-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bebd077a8ce5e6d011e95238d537e698ec174c7e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:58:47 2013 +0200

    ALSA: usx2y: Fix unlocked snd_pcm_stop() call

    commit 5be1efb4c2ed79c3d7c0cbcbecae768377666e84 upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f48a57b9b96e1e0f1acd60a3ca695fa75e41dc1f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:58:25 2013 +0200

    ALSA: ua101: Fix unlocked snd_pcm_stop() call

    commit 9538aa46c2427d6782aa10036c4da4c541605e0e upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f61b4c55035f73ad0e1acc140414c0855615285
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:57:55 2013 +0200

    ALSA: 6fire: Fix unlocked snd_pcm_stop() call

    commit 5b9ab3f7324a1b94a5a5a76d44cf92dfeb3b5e80 upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ca4b590cf2bf5676a76d15a477b2f5c41f13072
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 11 17:56:56 2013 +0200

    ALSA: atiixp: Fix unlocked snd_pcm_stop() call

    commit cc7282b8d5abbd48c81d1465925d464d9e3eaa8f upstream.

    snd_pcm_stop() must be called in the PCM substream lock context.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 404bbd6e4f0fd839b3bbffe0890adf51ac90170f
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Thu Jul 4 20:01:02 2013 -0300

    ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL

    commit 016fcab8ff46fca29375d484226ec91932aa4a07 upstream.

    According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL
    is 0x10.

    Reported-by: Oskar Schirmer <oskar@scara.com>
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    [bwh: Backported to 3.2: format of register defaults array is different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95cc4236d2ce87441db953e6dadf0e01d9ec0272
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Sun Mar 10 19:33:03 2013 +0100

    ASoC: imx-ssi: Fix occasional AC97 reset failure

    commit b6e51600f4e983e757b1b6942becaa1ae7d82e67 upstream.

    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1440cfb8325ee6bdbb87d97c7277a00bfc7221f9
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed May 22 12:57:24 2013 -0400

    SUNRPC: Prevent an rpc_task wakeup race

    commit a3c3cac5d31879cd9ae2de7874dc6544ca704aec upstream.

    The lockless RPC_IS_QUEUED() test in __rpc_execute means that we need to
    be careful about ordering the calls to rpc_test_and_set_running(task) and
    rpc_clear_queued(task). If we get the order wrong, then we may end up
    testing the RPC_TASK_RUNNING flag after __rpc_execute() has looped
    and changed the state of the rpc_task.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60b5861854edc34891c3d5388cdcc8bea2c1816b
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Jul 23 15:51:55 2012 -0400

    sunrpc: clarify comments on rpc_make_runnable

    commit 506026c3ec270e18402f0c9d33fee37482c23861 upstream.

    rpc_make_runnable is not generally called with the queue lock held, unless
    it's waking up a task that has been sitting on a waitqueue. This is safe
    when the task has not entered the FSM yet, but the comments don't really
    spell this out.

    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cb2d6808428297df5822d66e761ed311fd80490
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Thu Aug 15 13:21:07 2013 +0100

    xen/events: mask events when changing their VCPU binding

    commit 5e72fdb8d827560893642e85a251d339109a00f4 upstream.

    commit 4704fe4f03a5ab27e3c36184af85d5000e0f8a48 upstream.

    When a event is being bound to a VCPU there is a window between the
    EVTCHNOP_bind_vpcu call and the adjustment of the local per-cpu masks
    where an event may be lost.  The hypervisor upcalls the new VCPU but
    the kernel thinks that event is still bound to the old VCPU and
    ignores it.

    There is even a problem when the event is being bound to the same VCPU
    as there is a small window beween the clear_bit() and set_bit() calls
    in bind_evtchn_to_cpu().  When scanning for pending events, the kernel
    may read the bit when it is momentarily clear and ignore the event.

    Avoid this by masking the event during the whole bind operation.

    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    [bwh: Backported to 3.2: remove the BM() cast]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39d426fc13d3750fee7f619fa1d5b05bce1c8269
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Jan 23 16:54:32 2013 -0500

    xen/blkback: Check for insane amounts of request on the ring (v6).

    commit 9371cadbbcc7c00c81753b9727b19fb3bc74d458 upstream.

    commit 8e3f8755545cc4a7f4da8e9ef76d6d32e0dca576 upstream.

    Check that the ring does not have an insane amount of requests
    (more than there could fit on the ring).

    If we detect this case we will stop processing the requests
    and wait until the XenBus disconnects the ring.

    The existing check RING_REQUEST_CONS_OVERFLOW which checks for how
    many responses we have created in the past (rsp_prod_pvt) vs
    requests consumed (req_cons) and whether said difference is greater or
    equal to the size of the ring, does not catch this case.

    Wha the condition does check if there is a need to process more
    as we still have a backlog of responses to finish. Note that both
    of those values (rsp_prod_pvt and req_cons) are not exposed on the
    shared ring.

    To understand this problem a mini crash course in ring protocol
    response/request updates is in place.

    There are four entries: req_prod and rsp_prod; req_event and rsp_event
    to track the ring entries. We are only concerned about the first two -
    which set the tone of this bug.

    The req_prod is a value incremented by frontend for each request put
    on the ring. Conversely the rsp_prod is a value incremented by the backend
    for each response put on the ring (rsp_prod gets set by rsp_prod_pvt when
    pushing the responses on the ring).  Both values can
    wrap and are modulo the size of the ring (in block case that is 32).
    Please see RING_GET_REQUEST and RING_GET_RESPONSE for the more details.

    The culprit here is that if the difference between the
    req_prod and req_cons is greater than the ring size we have a problem.
    Fortunately for us, the '__do_block_io_op' loop:

    	rc = blk_rings->common.req_cons;
    	rp = blk_rings->common.sring->req_prod;

    	while (rc != rp) {

    		..
    		blk_rings->common.req_cons = ++rc; /* before make_response() */

    	}

    will loop up to the point when rc == rp. The macros inside of the
    loop (RING_GET_REQUEST) is smart and is indexing based on the modulo
    of the ring size. If the frontend has provided a bogus req_prod value
    we will loop until the 'rc == rp' - which means we could be processing
    already processed requests (or responses) often.

    The reason the RING_REQUEST_CONS_OVERFLOW is not helping here is
    b/c it only tracks how many responses we have internally produced
    and whether we would should process more. The astute reader will
    notice that the macro RING_REQUEST_CONS_OVERFLOW provides two
    arguments - more on this later.

    For example, if we were to enter this function with these values:

           	blk_rings->common.sring->req_prod =  X+31415 (X is the value from
    		the last time __do_block_io_op was called).
            blk_rings->common.req_cons = X
            blk_rings->common.rsp_prod_pvt = X

    The RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, blk_rings->common.req_cons)
    is doing:

    	req_cons - rsp_prod_pvt >= 32

    Which is,
    	X - X >= 32 or 0 >= 32

    And that is false, so we continue on looping (this bug).

    If we re-use said macro RING_REQUEST_CONS_OVERFLOW and pass in the rp
    instead (sring->req_prod) of rc, the this macro can do the check:

         req_prod - rsp_prov_pvt >= 32

    Which is,
           X + 31415 - X >= 32 , or 31415 >= 32

    which is true, so we can error out and break out of the function.

    Unfortunatly the difference between rsp_prov_pvt and req_prod can be
    at 32 (which would error out in the macro). This condition exists when
    the backend is lagging behind with the responses and still has not finished
    responding to all of them (so make_response has not been called), and
    the rsp_prov_pvt + 32 == req_cons. This ends up with us not being able
    to use said macro.

    Hence introducing a new macro called RING_REQUEST_PROD_OVERFLOW which does
    a simple check of:

        req_prod - rsp_prod_pvt > RING_SIZE

    And with the X values from above:

       X + 31415 - X > 32

    Returns true. Also not that if the ring is full (which is where
    the RING_REQUEST_CONS_OVERFLOW triggered), we would not hit the
    same condition:

       X + 32 - X > 32

    Which is false.

    Lets use that macro.
    Note that in v5 of this patchset the macro was different - we used an
    earlier version.

    [v1: Move the check outside the loop]
    [v2: Add a pr_warn as suggested by David]
    [v3: Use RING_REQUEST_CONS_OVERFLOW as suggested by Jan]
    [v4: Move wake_up after kthread_stop as suggested by Jan]
    [v5: Use RING_REQUEST_PROD_OVERFLOW instead]
    [v6: Use RING_REQUEST_PROD_OVERFLOW - Jan's version]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e331589db7664bf3735189fbd0f63fce609fcf84
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Jun 17 15:16:33 2013 -0400

    xen/io/ring.h: new macro to detect whether there are too many requests on the ring

    commit 8d9256906a97c24e97e016482b9be06ea2532b05 upstream.

    Backends may need to protect themselves against an insane number of
    produced requests stored by a frontend, in case they iterate over
    requests until reaching the req_prod value. There can't be more
    requests on the ring than the difference between produced requests
    and produced (but possibly not yet published) responses.

    This is a more strict alternative to a patch previously posted by
    Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>.

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75d94f08dd67a45717d115ec02366f108c52e614
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Apr 22 02:20:43 2013 +0000

    xen-netback: don't disconnect frontend when seeing oversize packet

    commit 03393fd5cc2b6cdeec32b704ecba64dbb0feae3c upstream.

    Some frontend drivers are sending packets > 64 KiB in length. This length
    overflows the length field in the first slot making the following slots have
    an invalid length.

    Turn this error back into a non-fatal error by dropping the packet. To avoid
    having the following slots having fatal errors, consume all slots in the
    packet.

    This does not reopen the security hole in XSA-39 as if the packet as an
    invalid number of slots it will still hit fatal error case.

    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c396fe32aba739ffe6fdf121eefa7f6bf32ad26a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Apr 22 02:20:42 2013 +0000

    xen-netback: coalesce slots in TX path and fix regressions

    commit 2810e5b9a7731ca5fce22bfbe12c96e16ac44b6f upstream.

    This patch tries to coalesce tx requests when constructing grant copy
    structures. It enables netback to deal with situation when frontend's
    MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.

    With the help of coalescing, this patch tries to address two regressions
    avoid reopening the security hole in XSA-39.

    Regression 1. The reduction of the number of supported ring entries (slots)
    per packet (from 18 to 17). This regression has been around for some time but
    remains unnoticed until XSA-39 security fix. This is fixed by coalescing
    slots.

    Regression 2. The XSA-39 security fix turning "too many frags" errors from
    just dropping the packet to a fatal error and disabling the VIF. This is fixed
    by coalescing slots (handling 18 slots when backend's MAX_SKB_FRAGS is 17)
    which rules out false positive (using 18 slots is legit) and dropping packets
    using 19 to `max_skb_slots` slots.

    To avoid reopening security hole in XSA-39, frontend sending packet using more
    than max_skb_slots is considered malicious.

    The behavior of netback for packet is thus:

        1-18            slots: valid
       19-max_skb_slots slots: drop and respond with an error
       max_skb_slots+   slots: fatal error

    max_skb_slots is configurable by admin, default value is 20.

    Also change variable name from "frags" to "slots" in netbk_count_requests.

    Please note that RX path still has dependency on MAX_SKB_FRAGS. This will be
    fixed with separate patch.

    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a697c49ebc0c2d9939e1a00d30595d73501ca3d6
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Wed Apr 10 10:54:46 2013 +0000

    xen-netback: fix sparse warning

    commit 9eaee8beeeb3bca0d9b14324fd9d467d48db784c upstream.

    Fix warning about 0 used as NULL.

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7a31d5528e08cd1e911bafaf4b3fccc274ce55c
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Apr 16 14:08:50 2013 -0400

    xen/smp/spinlock: Fix leakage of the spinlock interrupt line for every CPU online/offline

    commit 66ff0fe9e7bda8aec99985b24daad03652f7304e upstream.

    While we don't use the spinlock interrupt line (see for details
    commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23 -
    xen: disable PV spinlocks on HVM) - we should still do the proper
    init / deinit sequence. We did not do that correctly and for the
    CPU init for PVHVM guest we would allocate an interrupt line - but
    failed to deallocate the old interrupt line.

    This resulted in leakage of an irq_desc but more importantly this splat
    as we online an offlined CPU:

    genirq: Flags mismatch irq 71. 0002cc20 (spinlock1) vs. 0002cc20 (spinlock1)
    Pid: 2542, comm: init.late Not tainted 3.9.0-rc6upstream #1
    Call Trace:
     [<ffffffff811156de>] __setup_irq+0x23e/0x4a0
     [<ffffffff81194191>] ? kmem_cache_alloc_trace+0x221/0x250
     [<ffffffff811161bb>] request_threaded_irq+0xfb/0x160
     [<ffffffff8104c6f0>] ? xen_spin_trylock+0x20/0x20
     [<ffffffff813a8423>] bind_ipi_to_irqhandler+0xa3/0x160
     [<ffffffff81303758>] ? kasprintf+0x38/0x40
     [<ffffffff8104c6f0>] ? xen_spin_trylock+0x20/0x20
     [<ffffffff810cad35>] ? update_max_interval+0x15/0x40
     [<ffffffff816605db>] xen_init_lock_cpu+0x3c/0x78
     [<ffffffff81660029>] xen_hvm_cpu_notify+0x29/0x33
     [<ffffffff81676bdd>] notifier_call_chain+0x4d/0x70
     [<ffffffff810bb2a9>] __raw_notifier_call_chain+0x9/0x10
     [<ffffffff8109402b>] __cpu_notify+0x1b/0x30
     [<ffffffff8166834a>] _cpu_up+0xa0/0x14b
     [<ffffffff816684ce>] cpu_up+0xd9/0xec
     [<ffffffff8165f754>] store_online+0x94/0xd0
     [<ffffffff8141d15b>] dev_attr_store+0x1b/0x20
     [<ffffffff81218f44>] sysfs_write_file+0xf4/0x170
     [<ffffffff811a2864>] vfs_write+0xb4/0x130
     [<ffffffff811a302a>] sys_write+0x5a/0xa0
     [<ffffffff8167ada9>] system_call_fastpath+0x16/0x1b
    cpu 1 spinlock event irq -16
    smpboot: Booting Node 0 Processor 1 APIC 0x2

    And if one looks at the /proc/interrupts right after
    offlining (CPU1):

      70:          0          0  xen-percpu-ipi       spinlock0
      71:          0          0  xen-percpu-ipi       spinlock1
      77:          0          0  xen-percpu-ipi       spinlock2

    There is the oddity of the 'spinlock1' still being present.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5777db23b9767f3087b81834116173e4dbaac28
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Apr 16 13:49:26 2013 -0400

    xen/smp: Fix leakage of timer interrupt line for every CPU online/offline.

    commit 888b65b4bc5e7fcbbb967023300cd5d44dba1950 upstream.

    In the PVHVM path when we do CPU online/offline path we would
    leak the timer%d IRQ line everytime we do a offline event. The
    online path (xen_hvm_setup_cpu_clockevents via
    x86_cpuinit.setup_percpu_clockev) would allocate a new interrupt
    line for the timer%d.

    But we would still use the old interrupt line leading to:

    kernel BUG at /home/konrad/ssd/konrad/linux/kernel/hrtimer.c:1261!
    invalid opcode: 0000 [#1] SMP
    RIP: 0010:[<ffffffff810b9e21>]  [<ffffffff810b9e21>] hrtimer_interrupt+0x261/0x270
    .. snip..
     <IRQ>
     [<ffffffff810445ef>] xen_timer_interrupt+0x2f/0x1b0
     [<ffffffff81104825>] ? stop_machine_cpu_stop+0xb5/0xf0
     [<ffffffff8111434c>] handle_irq_event_percpu+0x7c/0x240
     [<ffffffff811175b9>] handle_percpu_irq+0x49/0x70
     [<ffffffff813a74a3>] __xen_evtchn_do_upcall+0x1c3/0x2f0
     [<ffffffff813a760a>] xen_evtchn_do_upcall+0x2a/0x40
     [<ffffffff8167c26d>] xen_hvm_callback_vector+0x6d/0x80
     <EOI>
     [<ffffffff81666d01>] ? start_secondary+0x193/0x1a8
     [<ffffffff81666cfd>] ? start_secondary+0x18f/0x1a8

    There is also the oddity (timer1) in the /proc/interrupts after
    offlining CPU1:

      64:       1121          0  xen-percpu-virq      timer0
      78:          0          0  xen-percpu-virq      timer1
      84:          0       2483  xen-percpu-virq      timer2

    This patch fixes it.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 397fd6b03c260a567cfd75d1ef5c13d53f5d64d4
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Sep 19 08:30:55 2012 -0400

    xen/boot: Disable BIOS SMP MP table search.

    commit bd49940a35ec7d488ae63bd625639893b3385b97 upstream.

    As the initial domain we are able to search/map certain regions
    of memory to harvest configuration data. For all low-level we
    use ACPI tables - for interrupts we use exclusively ACPI _PRT
    (so DSDT) and MADT for INT_SRC_OVR.

    The SMP MP table is not used at all. As a matter of fact we do
    not even support machines that only have SMP MP but no ACPI tables.

    Lets follow how Moorestown does it and just disable searching
    for BIOS SMP tables.

    This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

    9f->100 for 1:1 PTE
    Freeing 9f-100 pfn range: 97 pages freed
    1-1 mapping on 9f->100
    .. snip..
    e820: BIOS-provided physical RAM map:
    Xen: [mem 0x0000000000000000-0x000000000009efff] usable
    Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
    Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
    .. snip..
    Scan for SMP in [mem 0x00000000-0x000003ff]
    Scan for SMP in [mem 0x0009fc00-0x0009ffff]
    Scan for SMP in [mem 0x000f0000-0x000fffff]
    found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
    (XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
    (XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
    . snip..
    Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
    .. snip..
    Call Trace:
     [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
     [<ffffffff81624731>] ? printk+0x48/0x4a
     [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
     [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
     [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
     [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
     [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
     [<ffffffff81624731>] ? printk+0x48/0x4a
     [<ffffffff81abca7f>] start_kernel+0x90/0x390
     [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
     [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
    (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

    which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
    (which is what early_ioremap sticks as a flag) - which meant
    we would get MFN 0xFF (pte ff461, which is OK), and then it would
    also map 0x100 (b/c ioremap tries to get page aligned request, and
    it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
    as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
    bypasses the P2M lookup we would happily set the PTE to 1000461.
    Xen would deny the request since we do not have access to the
    Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
    0x80140.

    Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735c02dc85da96a464dde74781021f0b71658aac
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c731420c7f0e56e994deba2c484c3e5f1b15cf9
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Jan 12 16:19:36 2013 -0500

    ext4: return ENOMEM if sb_getblk() fails

    commit 860d21e2c585f7ee8a4ecc06f474fdc33c9474f4 upstream.

    The only reason for sb_getblk() failing is if it can't allocate the
    buffer_head.  So ENOMEM is more appropriate than EIO.  In addition,
    make sure that the file system is marked as being inconsistent if
    sb_getblk() fails.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    [xr: Backported to 3.4:
     - Drop change to inline.c
     - Call to ext4_ext_check() from ext4_ext_find_extent() is conditional]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8abd1c3c8f28f72dbf732ae856e65bd5c0e5066d
Author: Roland Dreier <roland@purestorage.com>
Date:   Thu Nov 22 02:00:11 2012 -0800

    block: Don't access request after it might be freed

    commit 893d290f1d7496db97c9471bc352ad4a11dc8a25 upstream.

    After we've done __elv_add_request() and __blk_run_queue() in
    blk_execute_rq_nowait(), the request might finish and be freed
    immediately.  Therefore checking if the type is REQ_TYPE_PM_RESUME
    isn't safe afterwards, because if it isn't, rq might be gone.
    Instead, check beforehand and stash the result in a temporary.

    This fixes crashes in blk_execute_rq_nowait() I get occasionally when
    running with lots of memory debugging options enabled -- I think this
    race is usually harmless because the window for rq to be reallocated
    is so small.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84554170a7ee8aa602ae7024365051f1ae51ae41
Author: Paul Clements <paul.clements@steeleye.com>
Date:   Wed Jul 3 15:09:04 2013 -0700

    nbd: correct disconnect behavior

    commit c378f70adbc1bbecd9e6db145019f14b2f688c7c upstream.

    Currently, when a disconnect is requested by the user (via NBD_DISCONNECT
    ioctl) the return from NBD_DO_IT is undefined (it is usually one of
    several error codes).  This means that nbd-client does not know if a
    manual disconnect was performed or whether a network error occurred.
    Because of this, nbd-client's persist mode (which tries to reconnect after
    error, but not after manual disconnect) does not always work correctly.

    This change fixes this by causing NBD_DO_IT to always return 0 if a user
    requests a disconnect.  This means that nbd-client can correctly either
    persist the connection (if an error occurred) or disconnect (if the user
    requested it).

    Signed-off-by: Paul Clements <paul.clements@steeleye.com>
    Acked-by: Rob Landley <rob@landley.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [xr: Backported to 3.4: adjust context]
    Signed-off-by: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15c796e60c439496ba26a1da1eb128ed71af1b93
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Dec 27 08:05:03 2012 -0500

    cifs: adjust sequence number downward after signing NT_CANCEL request

    commit 31efee60f489c759c341454d755a9fd13de8c03d upstream.

    When a call goes out, the signing code adjusts the sequence number
    upward by two to account for the request and the response. An NT_CANCEL
    however doesn't get a response of its own, it just hurries the server
    along to get it to respond to the original request more quickly.
    Therefore, we must adjust the sequence number back down by one after
    signing a NT_CANCEL request.

    Reported-by: Tim Perry <tdparmor-sambabugs@yahoo.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08272a8095857399198a8a2f5dd1f60df2c24ef9
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jan 29 22:48:17 2013 -0500

    ext4: fix possible use-after-free with AIO

    commit 091e26dfc156aeb3b73bc5c5f277e433ad39331c upstream.

    Running AIO is pinning inode in memory using file reference. Once AIO
    is completed using aio_complete(), file reference is put and inode can
    be freed from memory. So we have to be sure that calling aio_complete()
    is the last thing we do with the inode.

    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Acked-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit defb33881f5f61ffd79ca21937121f403d8bd824
Author: Adam Thomas <adamthomas1111@gmail.com>
Date:   Sat Feb 2 22:35:08 2013 +0000

    UBIFS: fix double free of ubifs_orphan objects

    commit 8afd500cb52a5d00bab4525dd5a560d199f979b9 upstream.

    The last orphan in the dnext list has its dnext set to NULL. Because
    of that, ubifs_delete_orphan assumes that it is not on the dnext list
    and frees it immediately instead ignoring it as a second delete. The
    orphan is later freed again by erase_deleted.

    This change adds an explicit flag to ubifs_orphan indicating whether
    it is pending delete.

    Signed-off-by: Adam Thomas <adamthomas1111@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016bc78b2f9cf093ceced760f77e219896cbe06c
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Apr 3 22:02:52 2013 -0400

    ext4/jbd2: don't wait (forever) for stale tid caused by wraparound

    commit d76a3a77113db020d9bb1e894822869410450bd9 upstream.

    In the case where an inode has a very stale transaction id (tid) in
    i_datasync_tid or i_sync_tid, it's possible that after a very large
    (2**31) number of transactions, that the tid number space might wrap,
    causing tid_geq()'s calculations to fail.

    Commit deeeaf13 "jbd2: fix fsync() tid wraparound bug", later modified
    by commit e7b04ac0 "jbd2: don't wake kjournald unnecessarily",
    attempted to fix this problem, but it only avoided kjournald spinning
    forever by fixing the logic in jbd2_log_start_commit().

    Unfortunately, in the codepaths in fs/ext4/fsync.c and fs/ext4/inode.c
    that might call jbd2_log_start_commit() with a stale tid, those
    functions will subsequently call jbd2_log_wait_commit() with the same
    stale tid, and then wait for a very long time.  To fix this, we
    replace the calls to jbd2_log_start_commit() and
    jbd2_log_wait_commit() with a call to a new function,
    jbd2_complete_transaction(), which will correctly handle stale tid's.

    As a bonus, jbd2_complete_transaction() will avoid locking
    j_state_lock for writing unless a commit needs to be started.  This
    should have a small (but probably not measurable) improvement for
    ext4's scalability.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Reported-by: George Barnett <gbarnett@atlassian.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f49b223d70f143d138008523b2a5d438d517def
Author: Dave Chiluk <chiluk@canonical.com>
Date:   Tue May 28 16:06:08 2013 -0500

    ncpfs: fix rmdir returns Device or resource busy

    commit 698b8223631472bf982ed570b0812faa61955683 upstream.

    1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
    directories could no longer be removed.  This was because ncp_rmdir checked
    to see if a dentry could be unhashed before allowing it to be removed. Since
    1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that incremented
    dentry->d_count causing it to always be greater than 1 unhash would always
    fail.  Thus causing the error path in ncp_rmdir to always be taken.  Removing
    this error path is safe as unhashing is still accomplished by calls to dput
    from vfs_rmdir.

    Signed-off-by: Dave Chiluk <chiluk@canonical.com>
    Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29826cebc84c251446f2e97b451b7b210161bdba
Author: Jeff Layton <jlayton@redhat.com>
Date:   Wed Aug 7 10:29:08 2013 -0400

    cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately

    commit 757c4f6260febff982276818bb946df89c1105aa upstream.

    David reported that commit c2b93e06 (cifs: only set ops for inodes in
    I_NEW state) caused a regression with mfsymlinks. Prior to that patch,
    if a mfsymlink dentry was instantiated at readdir time, the inode would
    get a new set of ops when it was revalidated. After that patch, this
    did not occur.

    This patch addresses this by simply skipping instantiating dentries in
    the readdir codepath when we know that they will need to be immediately
    revalidated. The next attempt to use that dentry will cause a new lookup
    to occur (which is basically what we want to happen anyway).

    Cc: "Stefan (metze) Metzmacher" <metze@samba.org>
    Cc: Sachin Prabhu <sprabhu@redhat.com>
    Reported-and-Tested-by: David McBride <dwm37@cam.ac.uk>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    [bwh: Backported to 3.2: need to return NULL]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 778e4fc5070c0a9750e72f677eb8887893d34234
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Jul 16 15:45:48 2013 +0800

    libceph: unregister request in __map_request failed and nofail == false

    commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.

    For nofail == false request, if __map_request failed, the caller does
    cleanup work, like releasing the relative pages.  It doesn't make any sense
    to retry this request.

    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db2a0091ff7a1b6d3491b965706e076984099b0a
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Aug 30 17:06:04 2013 +0400

    fuse: hotfix truncate_pagecache() issue

    commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.

    The way how fuse calls truncate_pagecache() from fuse_change_attributes()
    is completely wrong. Because, w/o i_mutex held, we never sure whether
    'oldsize' and 'attr->size' are valid by the time of execution of
    truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
    released fc->lock in the middle of fuse_change_attributes(), we completely
    loose control of actions which may happen with given inode until we reach
    truncate_pagecache. The list of potentially dangerous actions includes
    mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.

    The typical outcome of doing truncate_pagecache() with outdated arguments
    is data corruption from user point of view. This is (in some sense)
    acceptable in cases when the issue is triggered by a change of the file on
    the server (i.e. externally wrt fuse operation), but it is absolutely
    intolerable in scenarios when a single fuse client modifies a file without
    any external intervention. A real life case I discovered by fsx-linux
    looked like this:

    1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
    FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
    2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
    to the server synchronously, then calls fuse_change_attributes(). The
    latter updates i_size, releases fc->lock, but before comparing oldsize vs
    attr->size..
    3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
    updating attributes and i_size, but now oldsize is equal to
    outarg.attr.size because i_size has just been updated (step 2). Hence,
    fuse_do_setattr() returns w/o calling truncate_pagecache().
    4. As soon as ftruncate(2) completes, the user extends file size by
    write(2) making a hole in the middle of file, then reads data from the hole
    either by read(2) or mmap-ed read. The user expects to get zero data from
    the hole, but gets stale data because truncate_pagecache() is not executed
    yet.

    The scenario above illustrates one side of the problem: not truncating the
    page cache even though we should. Another side corresponds to truncating
    page cache too late, when the state of inode changed significantly.
    Theoretically, the following is possible:

    1. As in the previous scenario fuse_dentry_revalidate() discovered that
    i_size changed (due to our own fuse_do_setattr()) and is going to call
    truncate_pagecache() for some 'new_size' it believes valid right now. But
    by the time that particular truncate_pagecache() is called ...
    2. fuse_do_setattr() returns (either having called truncate_pagecache() or
    not -- it doesn't matter).
    3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
    4. mmap-ed write makes a page in the extended region dirty.

    The result will be the lost of data user wrote on the fourth step.

    The patch is a hotfix resolving the issue in a simplistic way: let's skip
    dangerous i_size update and truncate_pagecache if an operation changing
    file size is in progress. This simplistic approach looks correct for the
    cases w/o external changes. And to handle them properly, more sophisticated
    and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
    postpone it until the issue is well discussed on the mailing list(s).

    Changed in v2:
     - improved patch description to cover both sides of the issue.

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: add the fuse_inode::state field which we didn't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2c169d121e49e15957dc68928dba188b603a529
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Tue Sep 3 14:28:38 2013 +0200

    fuse: readdir: check for slash in names

    commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.

    Userspace can add names containing a slash character to the directory
    listing.  Don't allow this as it could cause all sorts of trouble.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: drop changes to parse_dirplusfile() which we
     don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbc83b378fbd904831108e125a1eee4c2fcf6c4d
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Mon Sep 30 13:45:12 2013 -0700

    nilfs2: fix issue with race condition of competition between segments for dirty blocks

    commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.

    Many NILFS2 users were reported about strange file system corruption
    (for example):

       NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
       NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)

    But such error messages are consequence of file system's issue that takes
    place more earlier.  Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
    and Anton Eliasson <devel@antoneliasson.se> were reported about another
    issue not so recently.  These reports describe the issue with segctor
    thread's crash:

      BUG: unable to handle kernel paging request at 0000000000004c83
      IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]

      Call Trace:
       nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
       nilfs_segctor_construct+0x17b/0x290 [nilfs2]
       nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
       kthread+0xc0/0xd0
       ret_from_fork+0x7c/0xb0

    These two issues have one reason.  This reason can raise third issue
    too.  Third issue results in hanging of segctor thread with eating of
    100% CPU.

    REPRODUCING PATH:

    One of the possible way or the issue reproducing was described by
    Jermoe me Poulin <jeromepoulin@gmail.com>:

    1. init S to get to single user mode.
    2. sysrq+E to make sure only my shell is running
    3. start network-manager to get my wifi connection up
    4. login as root and launch "screen"
    5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
    6. lscp | xz -9e > lscp.txt.xz
    7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
    8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
    9. start a screen and launch strace -f -o find-cat.log -t find
    /mnt/nilfs -type f -exec cat {} > /dev/null \;
    10. start a screen and launch strace -f -o apt-get.log -t apt-get update
    11. launch the last command again as it did not crash the first time
    12. apt-get crashes
    13. ps aux > ps-aux-crashed.log
    13. sysrq+W
    14. sysrq+E  wait for everything to terminate
    15. sysrq+SUSB

    Simplified way of the issue reproducing is starting kernel compilation
    task and "apt-get update" in parallel.

    REPRODUCIBILITY:

    The issue is reproduced not stable [60% - 80%].  It is very important to
    have proper environment for the issue reproducing.  The critical
    conditions for successful reproducing:

    (1) It should have big modified file by mmap() way.

    (2) This file should have the count of dirty blocks are greater that
        several segments in size (for example, two or three) from time to time
        during processing.

    (3) It should be intensive background activity of files modification
        in another thread.

    INVESTIGATION:

    First of all, it is possible to see that the reason of crash is not valid
    page address:

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
      NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783

    Moreover, value of b_page (0x1a82) is 6786.  This value looks like segment
    number.  And b_blocknr with b_size values look like block numbers.  So,
    buffer_head's pointer points on not proper address value.

    Detailed investigation of the issue is discovered such picture:

      [-----------------------------SEGMENT 6783-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783

      [-----------------------------SEGMENT 6784-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15

      [-----------------------------SEGMENT 6785-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12

      NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82

      BUG: unable to handle kernel paging request at 0000000000001a82
      IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]

    Usually, for every segment we collect dirty files in list.  Then, dirty
    blocks are gathered for every dirty file, prepared for write and
    submitted by means of nilfs_segbuf_submit_bh() call.  Finally, it takes
    place complete write phase after calling nilfs_end_bio_write() on the
    block layer.  Buffers/pages are marked as not dirty on final phase and
    processed files removed from the list of dirty files.

    It is possible to see that we had three prepare_write and submit_bio
    phases before segbuf_wait and complete_write phase.  Moreover, segments
    compete between each other for dirty blocks because on every iteration
    of segments processing dirty buffer_heads are added in several lists of
    payload_buffers:

      [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8

    The next pointer is the same but prev pointer has changed.  It means
    that buffer_head has next pointer from one list but prev pointer from
    another.  Such modification can be made several times.  And, finally, it
    can be resulted in various issues: (1) segctor hanging, (2) segctor
    crashing, (3) file system metadata corruption.

    FIX:
    This patch adds:

    (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
        for every proccessed dirty block;

    (2) checking of BH_Async_Write flag in
        nilfs_lookup_dirty_data_buffers() and
        nilfs_lookup_dirty_node_buffers();

    (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
        nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().

    Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
    Reported-by: Anton Eliasson <devel@antoneliasson.se>
    Cc: Paul Fertser <fercerpav@gmail.com>
    Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
    Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
    Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
    Cc: Elmer Zhang <freeboy6716@gmail.com>
    Cc: Kenneth Langga <klangga@gmail.com>
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: nilfs_clear_dirty_page() has not been separated
     from nilfs_clear_dirty_pages()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c1ae339696b33165b55c743ede5ffb32b309399
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Wed Sep 5 19:51:33 2012 +0200

    perf tools: Fix cache event name generation

    commit 275ef3878f698941353780440fec6926107a320b upstream.

    If the event name is specified with all 3 components, the last one
    overwrites the previous one during the name composing within the
    parse_events_add_cache function.

    Fixing this by properly adjusting the string index.

    Reported-by: Joel Uckelman <joel@lightboxtechnologies.com>
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Joel Uckelman <joel@lightboxtechnologies.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LPU-Reference: 20120905175133.GA18352@krava.brq.redhat.com
    [ committer note: Remove the newline fix, done already in 42e1fb7 ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Vinson Lee <vlee@twopensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f73d671a9a5226dbb63d602c00cbeca641b6641d
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Sep 6 14:43:28 2012 -0300

    perf tools: Remove extraneous newline when parsing hardware cache events

    commit 42e1fb776087713b5482cd7cf6cac998fbdd6544 upstream.

    Noticed while developing a 'perf test' entry to verify that
    perf_evsel__name works.

    Cc: David Ahern <dsahern@gmail.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Namhyung Kim <namhyung@gmail.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/n/tip-xz6zgh38mp3cjnd2udh38z8f@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Vinson Lee <vlee@twopensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b4fb44664b2ce8f8e3e2a7e88616b3de0244cb9
Author: Jiang Liu <jiang.liu@huawei.com>
Date:   Tue Jul 31 16:43:30 2012 -0700

    mm/hotplug: correctly add new zone to all other nodes' zone lists

    commit 08dff7b7d629807dbb1f398c68dd9cd58dd657a1 upstream.

    When online_pages() is called to add new memory to an empty zone, it
    rebuilds all zone lists by calling build_all_zonelists().  But there's a
    bug which prevents the new zone to be added to other nodes' zone lists.

    online_pages() {
    	build_all_zonelists()
    	.....
    	node_set_state(zone_to_nid(zone), N_HIGH_MEMORY)
    }

    Here the node of the zone is put into N_HIGH_MEMORY state after calling
    build_all_zonelists(), but build_all_zonelists() only adds zones from
    nodes in N_HIGH_MEMORY state to the fallback zone lists.
    build_all_zonelists()

        ->__build_all_zonelists()
    	->build_zonelists()
    	    ->find_next_best_node()
    		->for_each_node_state(n, N_HIGH_MEMORY)

    So memory in the new zone will never be used by other nodes, and it may
    cause strange behavor when system is under memory pressure.  So put node
    into N_HIGH_MEMORY state before calling build_all_zonelists().

    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Jiang Liu <liuj97@gmail.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Keping Chen <chenkeping@huawei.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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac9cb0397d36d327a623adf28445f7e7bd32d50
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Jun 25 11:48:32 2013 -0700

    cgroup: fix RCU accesses to task->cgroups

    commit 14611e51a57df10240817d8ada510842faf0ec51 upstream.

    task->cgroups is a RCU pointer pointing to struct css_set.  A task
    switches to a different css_set on cgroup migration but a css_set
    doesn't change once created and its pointers to cgroup_subsys_states
    aren't RCU protected.

    task_subsys_state[_check]() is the macro to acquire css given a task
    and subsys_id pair.  It RCU-dereferences task->cgroups->subsys[] not
    task->cgroups, so the RCU pointer task->cgroups ends up being
    dereferenced without read_barrier_depends() after it.  It's broken.

    Fix it by introducing task_css_set[_check]() which does
    RCU-dereference on task->cgroups.  task_subsys_state[_check]() is
    reimplemented to directly dereference ->subsys[] of the css_set
    returned from task_css_set[_check]().

    This removes some of sparse RCU warnings in cgroup.

    v2: Fixed unbalanced parenthsis and there's no need to use
        rcu_dereference_raw() when !CONFIG_PROVE_RCU.  Both spotted by Li.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Acked-by: Li Zefan <lizefan@huawei.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Remove CONFIG_PROVE_RCU condition
     - s/lockdep_is_held(&cgroup_mutex)/cgroup_lock_is_held()/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d220a1dfb0a318e71f2f6cc082c2c0f745120b9d
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Feb 25 21:32:25 2013 +0000

    proc connector: reject unprivileged listener bumps

    commit e70ab977991964a5a7ad1182799451d067e62669 upstream.

    While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
    for an unprivileged user to turn off notifications for all listeners by
    sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
    required for a multicast bind.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Evgeniy Polyakov <zbr@ioremap.net>
    Cc: Matt Helsley <matthltc@us.ibm.com>
    Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
    Acked-by: Matt Helsley <matthltc@us.ibm.com>
    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>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb839c95eaee06ba61ae683f145c140aabcf16e0
Author: Greg Edwards <gedwards@ddn.com>
Date:   Mon Nov 4 09:08:12 2013 -0700

    KVM: IOMMU: hva align mapping page size

    commit 27ef63c7e97d1e5dddd85051c03f8d44cc887f34 upstream.

    When determining the page size we could use to map with the IOMMU, the
    page size should also be aligned with the hva, not just the gfn.  The
    gfn may not reflect the real alignment within the hugetlbfs file.

    Most of the time, this works fine.  However, if the hugetlbfs file is
    backed by non-contiguous huge pages, a multi-huge page memslot starts at
    an unaligned offset within the hugetlbfs file, and the gfn is aligned
    with respect to the huge page size, kvm_host_page_size() will return the
    huge page size and we will use that to map with the IOMMU.

    When we later unpin that same memslot, the IOMMU returns the unmap size
    as the huge page size, and we happily unpin that many pfns in
    monotonically increasing order, not realizing we are spanning
    non-contiguous huge pages and partially unpin the wrong huge page.

    Ensure the IOMMU mapping page size is aligned with the hva corresponding
    to the gfn, which does reflect the alignment within the hugetlbfs file.

    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Edwards <gedwards@ddn.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    [bwh: Backported to 3.2: s/__gfn_to_hva_memslot/gfn_to_hva_memslot/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4564b7d79016e3826c02c5d50a77d9820b0ffb72
Author: Alexander Graf <agraf@suse.de>
Date:   Thu Jan 17 13:50:25 2013 +0100

    KVM: PPC: Emulate dcbf

    commit d3286144c92ec876da9e30320afa875699b7e0f1 upstream.

    Guests can trigger MMIO exits using dcbf. Since we don't emulate cache
    incoherent MMIO, just do nothing and move on.

    Reported-by: Ben Collins <ben.c@servergy.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>
    Tested-by: Ben Collins <ben.c@servergy.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e70173aaa6b49d8742faac1fb70f68ec82d2c67c
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Tue Oct 2 16:25:38 2012 +0200

    s390/kvm: dont announce RRBM support

    commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream.

    Newer kernels (linux-next with the transparent huge page patches)
    use rrbm if the feature is announced via feature bit 66.
    RRBM will cause intercepts, so KVM does not handle it right now,
    causing an illegal instruction in the guest.
    The  easy solution is to disable the feature bit for the guest.

    This fixes bugs like:
    Kernel BUG at 0000000000124c2a [verbose debug info unavailable]
    illegal operation: 0001 [#1] SMP
    Modules linked in: virtio_balloon virtio_net ipv6 autofs4
    CPU: 0 Not tainted 3.5.4 #1
    Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670)
    Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80)
         R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
         00000000003cc000 0000000000000004 0000000000000000 0000000079800000
         0000000000040000 0000000000000000 000000007bed3918 000000007cf40000
         0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c
         000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0
     Krnl Code:>0000000000124c2a: b9810025          ogr     %r2,%r5
               0000000000124c2e: 41343000           la      %r3,0(%r4,%r3)
               0000000000124c32: a716fffa           brct    %r1,124c26
               0000000000124c36: b9010022           lngr    %r2,%r2
               0000000000124c3a: e3d0f0800004       lg      %r13,128(%r15)
               0000000000124c40: eb22003f000c       srlg    %r2,%r2,63
    [ 2150.713198] Call Trace:
    [ 2150.713223] ([<00000000002312c4>] page_referenced_one+0x6c/0x27c)
    [ 2150.713749]  [<0000000000233812>] page_referenced+0x32a/0x410
    [...]

    CC: Alex Graf <agraf@suse.de>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 676caf7495427fa4e06f9016a842a5431f22af4a
Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
Date:   Fri Jul 26 15:04:00 2013 +0200

    KVM: s390: move kvm_guest_enter,exit closer to sie

    commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream.

    Any uaccess between guest_enter and guest_exit could trigger a page fault,
    the page fault handler would handle it as a guest fault and translate a
    user address as guest address.

    Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [hq: Backported to 3.4: adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 887b12db892173a6949734407a09678aa14c241e
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Oct 16 15:03:14 2012 -0700

    cgroup: cgroup_subsys->fork() should be called after the task is added to css_set

    commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.

    cgroup core has a bug which violates a basic rule about event
    notifications - when a new entity needs to be added, you add that to
    the notification list first and then make the new entity conform to
    the current state.  If done in the reverse order, an event happening
    inbetween will be lost.

    cgroup_subsys->fork() is invoked way before the new task is added to
    the css_set.  Currently, cgroup_freezer is the only user of ->fork()
    and uses it to make new tasks conform to the current state of the
    freezer.  If FROZEN state is requested while fork is in progress
    between cgroup_fork_callbacks() and cgroup_post_fork(), the child
    could escape freezing - the cgroup isn't frozen when ->fork() is
    called and the freezer couldn't see the new task on the css_set.

    This patch moves cgroup_subsys->fork() invocation to
    cgroup_post_fork() after the new task is added to the css_set.
    cgroup_fork_callbacks() is removed.

    Because now a task may be migrated during cgroup_subsys->fork(),
    freezer_fork() is updated so that it adheres to the usual RCU locking
    and the rather pointless comment on why locking can be different there
    is removed (if it doesn't make anything simpler, why even bother?).

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    [hq: Backported to 3.4:
     - Adjust context
     - Iterate over first CGROUP_BUILTIN_SUBSYS_COUNT elements of subsys]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70892781014ad0041620d0799abff6a41569dffb
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Nov 29 13:54:23 2012 -0800

    mm: vmscan: fix endless loop in kswapd balancing

    commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.

    Kswapd does not in all places have the same criteria for a balanced
    zone.  Zones are only being reclaimed when their high watermark is
    breached, but compaction checks loop over the zonelist again when the
    zone does not meet the low watermark plus two times the size of the
    allocation.  This gets kswapd stuck in an endless loop over a small
    zone, like the DMA zone, where the high watermark is smaller than the
    compaction requirement.

    Add a function, zone_balanced(), that checks the watermark, and, for
    higher order allocations, if compaction has enough free memory.  Then
    use it uniformly to check for balanced zones.

    This makes sure that when the compaction watermark is not met, at least
    reclaim happens and progress is made - or the zone is declared
    unreclaimable at some point and skipped entirely.

    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: George Spelvin <linux@horizon.com>
    Reported-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reported-by: Tomas Racek <tracek@redhat.com>
    Tested-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [hq: Backported to 3.4: adjust context]
    Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47c4e3144c6a31f12f17ff4a21be6fc9abfdb13f
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Feb 26 10:07:04 2014 +0100

    dm mpath: fix stalls when handling invalid ioctls

    commit a1989b330093578ea5470bea0a00f940c444c466 upstream.

    An invalid ioctl will never be valid, irrespective of whether multipath
    has active paths or not.  So for invalid ioctls we do not have to wait
    for multipath to activate any paths, but can rather return an error
    code immediately.  This fix resolves numerous instances of:

     udevd[]: worker [] unexpectedly returned with status 0x0100

    that have been seen during testing.

    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b1ac9122778967dcb4da87ec0a46cdfca760d57
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddf7ce352171a71b87c4910b4fafd3a9aa5b7094
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 880787abfd3354a099ef61f522447cc52d8f051b
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da1b0b00e4dc76de2bb32268ed7b2501e0a6599f
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cc59cdc304d3890446c33b2203d967d6fae84da
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 461700f19780f0a305571c598040cda487c936d9
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb6e1ff8476ab9b85c3da008f22e4424e48b701
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>

commit ef6ea5278212c5eb4fe75873adb4535ea236dd9d
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>

commit 00c3a0efb8c92d34ecac123e896ef4d1ad5d7636
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6158ca02eeaa3b81fdaa1fb69d7cab9f71e204f9
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9128e00219359ce9d9b7055f71db96b8ff0a2b39
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21d5c26f3bcec31e7b6b9926580cff0d1a38d9ec
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c40074869a0437eb3271000256ca7fedba6b52a
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef0972fa642ad16444d0e69edd2afed5a301df86
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4082d95b82b87451a1f182e05d7169683a0d9824
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21d846eb4e6aeadb8917800c97921197f189f701
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9343234d19b0cff37c27398ee725eec75f67064e
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Sat Feb 22 18:30:13 2014 +0100

    ASoC: wm8958-dsp: Fix firmware block loading

    commit 548da08fc1e245faf9b0d7c41ecd8e07984fc332 upstream.

    The codec->control_data contains a pointer to the device's regmap struct. But
    wm8994_bulk_write() expects a pointer to the parent wm8998 device.

    The issue was introduced in commit d9a7666f ("ASoC: Remove ASoC-specific
    WM8994 I/O code").

    Fixes: d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9db442003d2ba9522db42105ddfec9f7ed5abdd9
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba38ea649fb31d7d21debf2977e988628fe36bf7
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 635ed4f43e60df21a30765446ed2be6929d68bac
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92732d6f296638d3912eddc6700ad8306cec2c97
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abe98d8076e08030181b0067055e115a22839024
Author: Florian Westphal <fw@strlen.de>
Date:   Sat Feb 22 10:33:26 2014 +0100

    net: ip, ipv6: handle gso skbs in forwarding path

    commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.

    [ use zero netdev_feature mask to avoid backport of
      netif_skb_dev_features function ]

    Marcelo Ricardo Leitner reported problems when the forwarding link path
    has a lower mtu than the incoming one if the inbound interface supports GRO.

    Given:
    Host <mtu1500> R1 <mtu1200> R2

    Host sends tcp stream which is routed via R1 and R2.  R1 performs GRO.

    In this case, the kernel will fail to send ICMP fragmentation needed
    messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
    checks in forward path. Instead, Linux tries to send out packets exceeding
    the mtu.

    When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
    not fragment the packets when forwarding, and again tries to send out
    packets exceeding R1-R2 link mtu.

    This alters the forwarding dstmtu checks to take the individual gso
    segment lengths into account.

    For ipv6, we send out pkt too big error for gso if the individual
    segments are too big.

    For ipv4, we either send icmp fragmentation needed, or, if the DF bit
    is not set, perform software segmentation and let the output path
    create fragments when the packet is leaving the machine.
    It is not 100% correct as the error message will contain the headers of
    the GRO skb instead of the original/segmented one, but it seems to
    work fine in my (limited) tests.

    Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
    sofware segmentation.

    However it turns out that skb_segment() assumes skb nr_frags is related
    to mss size so we would BUG there.  I don't want to mess with it considering
    Herbert and Eric disagree on what the correct behavior should be.

    Hannes Frederic Sowa notes that when we would shrink gso_size
    skb_segment would then also need to deal with the case where
    SKB_MAX_FRAGS would be exceeded.

    This uses sofware segmentation in the forward path when we hit ipv4
    non-DF packets and the outgoing link mtu is too small.  Its not perfect,
    but given the lack of bug reports wrt. GRO fwd being broken this is a
    rare case anyway.  Also its not like this could not be improved later
    once the dust settles.

    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5625d74932c842fa92eac14c9cc36cfcc1826108
Author: Florian Westphal <fw@strlen.de>
Date:   Sat Feb 22 10:33:25 2014 +0100

    net: add and use skb_gso_transport_seglen()

    commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.

    [ no skb_gso_seglen helper in 3.4, leave tbf alone ]

    This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
    skbuff core so it may be reused by upcoming ip forwarding path patch.

    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b976c428f7a071ed9e96b5fce5d0e35d6f62d640
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f62bad5674439f35dd9ffa65a54d6695a1ef2e
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6b13895fcb7d1056a5e76eb361c4212d3ff4269
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd77f2a56490366afe59d7685c7714236ba90dbd
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 181f00c45c932571da565c3412e0d835e1b699b7
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d965377d3d83fac117f574ba7728109b8de63a8
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 437c448368fc6ee339fc4b8b8ddc027a8096798d
Author: Olivier Langlois <olivier@trillion01.com>
Date:   Sat Feb 1 01:11:10 2014 -0500

    rtlwifi: Fix incorrect return from rtl_ps_enable_nic()

    commit 2e8c5e56b307271c2dab6f8bfd1d8a3822ca2390 upstream.

    rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
    maximum number of retries is performed.

    hw_init() returns non-zero on error. In that situation return false to
    restore the original design intent to retry hw init when it fails.

    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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a91ab9d7596e600503c7d6da4f21adbe27fb867e
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b45356e58a666156a6b683ce410cc91674a8e2c0
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri Feb 14 07:20:35 2014 -0500

    cifs: ensure that uncached writes handle unmapped areas correctly

    commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream.

    It's possible for userland to pass down an iovec via writev() that has a
    bogus user pointer in it. If that happens and we're doing an uncached
    write, then we can end up getting less bytes than we expect from the
    call to iov_iter_copy_from_user. This is CVE-2014-0069

    cifs_iovec_write isn't set up to handle that situation however. It'll
    blindly keep chugging through the page array and not filling those pages
    with anything useful. Worse yet, we'll later end up with a negative
    number in wdata->tailsz, which will confuse the sending routines and
    cause an oops at the very least.

    Fix this by having the copy phase of cifs_iovec_write stop copying data
    in this situation and send the last write as a short one. At the same
    time, we want to avoid sending a zero-length write to the server, so
    break out of the loop and set rc to -EFAULT if that happens. This also
    allows us to handle the case where no address in the iovec is valid.

    [Note: Marking this for stable on v3.4+ kernels, but kernels as old as
           v2.6.38 may have a similar problem and may need similar fix]

    Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b846a0419b9de1b931e0c7f7c5f28ab4b49f7af
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4f15262e9fdde36c1cca1575098562194cbcb39
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 042845797eb524fc838c06b4ed62884ab51a5438
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7f6e8baaa6101e7cf140a8c04a01d78e3b6b6bf
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3188401fafc0b14a810cd5948c8a145dd14d0bd
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Feb 15 22:42:25 2014 -0500

    ext4: fix online resize with a non-standard blocks per group setting

    commit 3d2660d0c9c2f296837078c189b68a47f6b2e3b5 upstream.

    The set_flexbg_block_bitmap() function assumed that the number of
    blocks in a blockgroup was sb->blocksize * 8, which is normally true,
    but not always!  Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block
    bitmap corruption after:

    mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G
    mount -t ext4 /dev/vdd /vdd
    resize2fs /dev/vdd 8G

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reported-by: Jon Bernard <jbernard@tuxion.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f3652715f115db6bca9299a66738fd5e7395c84
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Feb 12 12:16:04 2014 -0500

    ext4: don't try to modify s_flags if the the file system is read-only

    commit 23301410972330c0ae9a8afc379ba2005e249cc6 upstream.

    If an ext4 file system is created by some tool other than mke2fs
    (perhaps by someone who has a pathalogical fear of the GPL) that
    doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags,
    and that file system is then mounted read-only, don't try to modify
    the s_flags field.  Otherwise, if dm_verity is in use, the superblock
    will change, causing an dm_verity failure.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>