commit 43d8b1ef8250705d07fadceefa44f91b32e08328
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Nov 29 11:12:03 2013 -0800

    Linux 3.10.21

commit 215948b12e93e724923ea0cac10ffbb5a36a0a5a
Author: Rob Pearce <rob@flitspace.org.uk>
Date:   Sun Oct 27 16:13:42 2013 +0000

    drm/i915: No LVDS hardware on Intel D410PT and D425KT
    
    commit 645378d85ee524e429aa4cf52806047b56cdc596 upstream.
    
    The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
    having LVDS but the hardware is not populated. This patch adds them to
    the list of such systems. Patch is against 3.11.4
    
    v2: Patch revised to match the D425KT exactly as the D425KTW does have
    LVDS.  According to Intel's documentation, the D410PTL and D410PLTW
    don't.
    
    Signed-off-by: Rob Pearce <rob@flitspace.org.uk>
    [danvet: Pimp commit message to my liking and add cc: stable.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2df22e6f70c2b4f9204f47d6d471fd2a6691e393
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 3 15:05:03 2013 -0700

    drm/i915: quirk away phantom LVDS on Intel's D510MO mainboard
    
    commit e5614f0c2d0f4d7f0b8ef745d34593baf2c5dbf8 upstream.
    
    This replaceable mainboard only has a VGA-out, yet it claims to also have
    a connected LVDS header.
    
    Addresses https://bugs.freedesktop.org/show_bug.cgi?id=63860
    
    [jani.nikula@intel.com: use DMI_EXACT_MATCH for board name.]
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reported-by: <annndddrr@gmail.com>
    Cc: Cornel Panceac <cpanceac@gmail.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    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 e3e129e720552f0dbc8ad363f8e85120219dac94
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Jul 3 15:05:02 2013 -0700

    dmi: add support for exact DMI matches in addition to substring matching
    
    commit 5017b2851373ee15c7035151853bb1448800cae2 upstream.
    
    dmi_match() considers a substring match to be a successful match.  This is
    not always sufficient to distinguish between DMI data for different
    systems.  Add support for exact string matching using strcmp() in addition
    to the substring matching using strstr().
    
    The specific use case in the i915 driver is to allow us to use an exact
    match for D510MO, without also incorrectly matching D510MOV:
    
      {
    	.ident = "Intel D510MO",
    	.matches = {
    		DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
    		DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
    	},
      }
    
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Cc: <annndddrr@gmail.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Cornel Panceac <cpanceac@gmail.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    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 a8e25439e373f9e2ec3ad7db6ddf0e32429d9ec0
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date:   Tue Nov 12 15:06:49 2013 -0800

    cris: media platform drivers: fix build
    
    commit 72a0c5571351f5184195754d23db3e14495b2080 upstream.
    
    On cris arch, the functions below aren't defined:
    
      drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
    
      drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
      drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
    
      drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
      drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
      drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
      drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
      drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
      drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
      drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
      drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
      drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
      drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
      drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
    
      drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
      drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
    
    Yet, they're available, as CONFIG_GENERIC_IOMAP is defined.  What happens
    is that asm/io.h was not including asm-generic/iomap.h.
    
    Suggested-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Cc: Mikael Starvik <starvik@axis.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.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 7a4ca2033fd051599a862ab1d05707677143a9ef
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Nov 21 14:31:56 2013 -0800

    configfs: fix race between dentry put and lookup
    
    commit 76ae281f6307331aa063288edb6422ae99f435f0 upstream.
    
    A race window in configfs, it starts from one dentry is UNHASHED and end
    before configfs_d_iput is called.  In this window, if a lookup happen,
    since the original dentry was UNHASHED, so a new dentry will be
    allocated, and then in configfs_attach_attr(), sd->s_dentry will be
    updated to the new dentry.  Then in configfs_d_iput(),
    BUG_ON(sd->s_dentry != dentry) will be triggered and system panic.
    
    sys_open:                     sys_close:
     ...                           fput
                                    dput
                                     dentry_kill
                                      __d_drop <--- dentry unhashed here,
                                               but sd->dentry still point
                                               to this dentry.
    
     lookup_real
      configfs_lookup
       configfs_attach_attr---> update sd->s_dentry
                                to new allocated dentry here.
    
                                       d_kill
                                         configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry)
                                                         triggered here.
    
    To fix it, change configfs_d_iput to not update sd->s_dentry if
    sd->s_count > 2, that means there are another dentry is using the sd
    beside the one that is going to be put.  Use configfs_dirent_lock in
    configfs_attach_attr to sync with configfs_d_iput.
    
    With the following steps, you can reproduce the bug.
    
    1. enable ocfs2, this will mount configfs at /sys/kernel/config and
       fill configure in it.
    
    2. run the following script.
    	while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &
    	while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &
    
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4f2a840c79ca283a453b9cd6329ccb530cb0f70
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Oct 28 12:15:32 2013 +0100

    s390/vtime: correct idle time calculation
    
    commit 4560e7c3317c7a2b370e36dadd3a3bac2ed70818 upstream.
    
    Use the ACCESS_ONCE macro for both accesses to idle->sequence in the
    loops to calculate the idle time. If only one access uses the macro,
    the compiler is free to cache the value for the second access which
    can cause endless loops.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3170c7a91c9520eeb6d2c13d0897172ebd6c228
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Oct 18 11:36:54 2013 +0200

    rt2800usb: slow down TX status polling
    
    commit 36165fd5b00bf8163f89c21bb16a3e9834555b10 upstream.
    
    Polling TX statuses too frequently has two negative effects. First is
    randomly peek CPU usage, causing overall system functioning delays.
    Second bad effect is that device is not able to fill TX statuses in
    H/W register on some workloads and we get lot of timeouts like below:
    
    ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
    ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
    ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
    
    This not only cause flood of messages in dmesg, but also bad throughput,
    since rate scaling algorithm can not work optimally.
    
    In the future, we should probably make polling interval be adjusted
    automatically, but for now just increase values, this make mentioned
    problems gone.
    
    Resolve:
    https://bugzilla.kernel.org/show_bug.cgi?id=62781
    
    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 1316580f10273f89629cc197f59cc7ad96d9605e
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>

commit bd7e08189efba225bfa173372b05682ac141af88
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Mon Oct 21 22:05:38 2013 +0300

    mei: nfc: fix memory leak in error path
    
    commit 4bff7208f332b2b1d7cf1338e50527441283a198 upstream.
    
    The flow may reach the err label without freeing cl and cl_info
    
    cl and cl_info weren't assigned to ndev->cl and cl_info
    so they weren't freed in mei_nfc_free called on error path
    
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7adb120526cf06bc2c0a8449194172ecfb62c730
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Nov 8 16:03:50 2013 -0500

    SUNRPC: Fix a data corruption issue when retransmitting RPC calls
    
    commit a6b31d18b02ff9d7915c5898c9b5ca41a798cd73 upstream.
    
    The following scenario can cause silent data corruption when doing
    NFS writes. It has mainly been observed when doing database writes
    using O_DIRECT.
    
    1) The RPC client uses sendpage() to do zero-copy of the page data.
    2) Due to networking issues, the reply from the server is delayed,
       and so the RPC client times out.
    
    3) The client issues a second sendpage of the page data as part of
       an RPC call retransmission.
    
    4) The reply to the first transmission arrives from the server
       _before_ the client hardware has emptied the TCP socket send
       buffer.
    5) After processing the reply, the RPC state machine rules that
       the call to be done, and triggers the completion callbacks.
    6) The application notices the RPC call is done, and reuses the
       pages to store something else (e.g. a new write).
    
    7) The client NIC drains the TCP socket send buffer. Since the
       page data has now changed, it reads a corrupted version of the
       initial RPC call, and puts it on the wire.
    
    This patch fixes the problem in the following manner:
    
    The ordering guarantees of TCP ensure that when the server sends a
    reply, then we know that the _first_ transmission has completed. Using
    zero-copy in that situation is therefore safe.
    If a time out occurs, we then send the retransmission using sendmsg()
    (i.e. no zero-copy), We then know that the socket contains a full copy of
    the data, and so it will retransmit a faithful reproduction even if the
    RPC call completes, and the application reuses the O_DIRECT buffer in
    the meantime.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe76407da71233f8b172e2eabaf58a9d3dccf894
Author: Christoph Lameter <cl@linux.com>
Date:   Thu Nov 7 16:29:15 2013 +0000

    slub: Handle NULL parameter in kmem_cache_flags
    
    commit c6f58d9b362b45c52afebe4342c9137d0dabe47f upstream.
    
    Andreas Herrmann writes:
    
      When I've used slub_debug kernel option (e.g.
      "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've
      seen a panic like:
    
        Highbank #setenv bootargs console=ttyAMA0 root=/dev/sda2 kgdboc.kgdboc=ttyAMA0,115200 slub_debug=,kmalloc-4096 earlyprintk=ttyAMA0
        ...
        Unable to handle kernel NULL pointer dereference at virtual address 00000000
        pgd = c0004000
        [00000000] *pgd=00000000
        Internal error: Oops: 5 [#1] SMP ARM
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Tainted: G        W    3.12.0-00048-gbe408cd #314
        task: c0898360 ti: c088a000 task.ti: c088a000
        PC is at strncmp+0x1c/0x84
        LR is at kmem_cache_flags.isra.46.part.47+0x44/0x60
        pc : [<c02c6da0>]    lr : [<c0110a3c>]    psr: 200001d3
        sp : c088bea8  ip : c088beb8  fp : c088beb4
        r10: 00000000  r9 : 413fc090  r8 : 00000001
        r7 : 00000000  r6 : c2984a08  r5 : c0966e78  r4 : 00000000
        r3 : 0000006b  r2 : 0000000c  r1 : 00000000  r0 : c2984a08
        Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
        Control: 10c5387d  Table: 0000404a  DAC: 00000015
        Process swapper (pid: 0, stack limit = 0xc088a248)
        Stack: (0xc088bea8 to 0xc088c000)
        bea0:                   c088bed4 c088beb8 c0110a3c c02c6d90 c0966e78 00000040
        bec0: ef001f00 00000040 c088bf14 c088bed8 c0112070 c0110a04 00000005 c010fac8
        bee0: c088bf5c c088bef0 c010fac8 ef001f00 00000040 00000000 00000040 00000001
        bf00: 413fc090 00000000 c088bf34 c088bf18 c0839190 c0112040 00000000 ef001f00
        bf20: 00000000 00000000 c088bf54 c088bf38 c0839200 c083914c 00000006 c0961c4c
        bf40: c0961c28 00000000 c088bf7c c088bf58 c08392ac c08391c0 c08a2ed8 c0966e78
        bf60: c086b874 c08a3f50 c0961c28 00000001 c088bfb4 c088bf80 c083b258 c0839248
        bf80: 2f800000 0f000000 c08935b4 ffffffff c08cd400 ffffffff c08cd400 c0868408
        bfa0: c29849c0 00000000 c088bff4 c088bfb8 c0824974 c083b1e4 ffffffff ffffffff
        bfc0: c08245c0 00000000 00000000 c0868408 00000000 10c5387d c0892bcc c0868404
        bfe0: c0899440 0000406a 00000000 c088bff8 00008074 c0824824 00000000 00000000
        [<c02c6da0>] (strncmp+0x1c/0x84) from [<c0110a3c>] (kmem_cache_flags.isra.46.part.47+0x44/0x60)
        [<c0110a3c>] (kmem_cache_flags.isra.46.part.47+0x44/0x60) from [<c0112070>] (__kmem_cache_create+0x3c/0x410)
        [<c0112070>] (__kmem_cache_create+0x3c/0x410) from [<c0839190>] (create_boot_cache+0x50/0x74)
        [<c0839190>] (create_boot_cache+0x50/0x74) from [<c0839200>] (create_kmalloc_cache+0x4c/0x88)
        [<c0839200>] (create_kmalloc_cache+0x4c/0x88) from [<c08392ac>] (create_kmalloc_caches+0x70/0x114)
        [<c08392ac>] (create_kmalloc_caches+0x70/0x114) from [<c083b258>] (kmem_cache_init+0x80/0xe0)
        [<c083b258>] (kmem_cache_init+0x80/0xe0) from [<c0824974>] (start_kernel+0x15c/0x318)
        [<c0824974>] (start_kernel+0x15c/0x318) from [<00008074>] (0x8074)
        Code: e3520000 01a00002 089da800 e5d03000 (e5d1c000)
        ---[ end trace 1b75b31a2719ed1d ]---
        Kernel panic - not syncing: Fatal exception
    
      Problem is that slub_debug option is not parsed before
      create_boot_cache is called. Solve this by changing slub_debug to
      early_param.
    
      Kernels 3.11, 3.10 are also affected.  I am not sure about older
      kernels.
    
    Christoph Lameter explains:
    
      kmem_cache_flags may be called with NULL parameter during early boot.
      Skip the test in that case.
    
    Reported-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 826b7a8cc660c8412ae6c8c7bb258c875dd0dbc2
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed Nov 20 16:18:54 2013 +1100

    powerpc/signals: Mark VSX not saved with small contexts
    
    commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 upstream.
    
    The VSX MSR bit in the user context indicates if the context contains VSX
    state.  Currently we set this when the process has touched VSX at any stage.
    
    Unfortunately, if the user has not provided enough space to save the VSX state,
    we can't save it but we currently still set the MSR VSX bit.
    
    This patch changes this to clear the MSR VSX bit when the user doesn't provide
    enough space.  This indicates that there is no valid VSX state in the user
    context.
    
    This is needed to support get/set/make/swapcontext for applications that use
    VSX but only provide a small context.  For example, getcontext in glibc
    provides a smaller context since the VSX registers don't need to be saved over
    the glibc function call.  But since the program calling getcontext may have
    used VSX, the kernel currently says the VSX state is valid when it's not.  If
    the returned context is then used in setcontext (ie. a small context without
    VSX but with MSR VSX set), the kernel will refuse the context.  This situation
    has been reported by the glibc community.
    
    Based on patch from Carlos O'Donell.
    
    Tested-by: Haren Myneni <haren@linux.vnet.ibm.com>
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ee8b4e1d91204180081d04c964ee5e0c7387f27
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Nov 18 14:55:28 2013 +1100

    powerpc: ppc64 address space capped at 32TB, mmap randomisation disabled
    
    commit 5a049f14902982c26538250bdc8d54156d357252 upstream.
    
    Commit fba2369e6ceb (mm: use vm_unmapped_area() on powerpc architecture)
    has a bug in slice_scan_available() where we compare an unsigned long
    (high_slices) against a shifted int. As a result, comparisons against
    the top 32 bits of high_slices (representing the top 32TB) always
    returns 0 and the top of our mmap region is clamped at 32TB
    
    This also breaks mmap randomisation since the randomised address is
    always up near the top of the address space and it gets clamped down
    to 32TB.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36cfdef6ffa08c5f3b1f812332eddd8aa4d91ed2
Author: Gavin Shan <shangw@linux.vnet.ibm.com>
Date:   Mon Nov 4 16:32:46 2013 +0800

    powerpc/powernv: Add PE to its own PELTV
    
    commit 631ad691b5818291d89af9be607d2fe40be0886e upstream.
    
    We need add PE to its own PELTV. Otherwise, the errors originated
    from the PE might contribute to other PEs. In the result, we can't
    clear up the error successfully even we're checking and clearing
    errors during access to PCI config space.
    
    Reported-by: kalshett@in.ibm.com
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2db1eb6794f761bc90ae128c0694874bf572579
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Thu Oct 17 08:00:11 2013 -0400

    powerpc/vio: use strcpy in modalias_show
    
    commit 411cabf79e684171669ad29a0628c400b4431e95 upstream.
    
    Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
    strcpy which can result in an overflow of newlines on the buffer.
    
    Signed-off-by: Prarit Bhargava
    Cc: benh@kernel.crashing.org
    Cc: ben@decadent.org.uk
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae4c6cbd0a56bcea14bf35168076b9ad5bd3203f
Author: Anatolij Gustschin <agust@denx.de>
Date:   Wed Oct 16 13:11:27 2013 +0200

    powerpc/52xx: fix build breakage for MPC5200 LPBFIFO module
    
    commit 2bf75084f6d9f9a91ba6e30a501ff070d8a1acf6 upstream.
    
    The MPC5200 LPBFIFO driver requires the bestcomm module to be
    enabled, otherwise building will fail. Fix it.
    
    Reported-by: Wolfgang Denk <wd@denx.de>
    Signed-off-by: Anatolij Gustschin <agust@denx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0deb6f9cb87494f6646fb014f09b41d3ded76c63
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Oct 18 09:44:49 2013 -0600

    block: properly stack underlying max_segment_size to DM device
    
    commit d82ae52e68892338068e7559a0c0657193341ce4 upstream.
    
    Without this patch all DM devices will default to BLK_MAX_SEGMENT_SIZE
    (65536) even if the underlying device(s) have a larger value -- this is
    due to blk_stack_limits() using min_not_zero() when stacking the
    max_segment_size limit.
    
    1073741824
    
    before patch:
    65536
    
    after patch:
    1073741824
    
    Reported-by: Lukasz Flis <l.flis@cyfronet.pl>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12e6e9c2a578d3a2f0474d48d845f796361a90c0
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Oct 14 12:13:24 2013 -0400

    block: fix a probe argument to blk_register_region
    
    commit a207f5937630dd35bd2550620bef416937a1365e upstream.
    
    The probe function is supposed to return NULL on failure (as we can see in
    kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj;
    
    However, in loop and brd, it returns negative error from ERR_PTR.
    
    This causes a crash if we simulate disk allocation failure and run
    less -f /dev/loop0 because the negative number is interpreted as a pointer:
    
    BUG: unable to handle kernel NULL pointer dereference at 00000000000002b4
    IP: [<ffffffff8118b188>] __blkdev_get+0x28/0x450
    PGD 23c677067 PUD 23d6d1067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia]
    CPU: 1 PID: 6831 Comm: less Tainted: P        W  O 3.10.15-devel #18
    Hardware name: empty empty/S3992-E, BIOS 'V1.06   ' 06/09/2009
    task: ffff880203cc6bc0 ti: ffff88023e47c000 task.ti: ffff88023e47c000
    RIP: 0010:[<ffffffff8118b188>]  [<ffffffff8118b188>] __blkdev_get+0x28/0x450
    RSP: 0018:ffff88023e47dbd8  EFLAGS: 00010286
    RAX: ffffffffffffff74 RBX: ffffffffffffff74 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001
    RBP: ffff88023e47dc18 R08: 0000000000000002 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff88023f519658
    R13: ffffffff8118c300 R14: 0000000000000000 R15: ffff88023f519640
    FS:  00007f2070bf7700(0000) GS:ffff880247400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000000002b4 CR3: 000000023da1d000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640
     ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60
     ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292
    Call Trace:
     [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
     [<ffffffff8118c10d>] blkdev_get+0x1dd/0x370
     [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
     [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
     [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
     [<ffffffff8118c365>] blkdev_open+0x65/0x80
     [<ffffffff8114d12e>] do_dentry_open.isra.18+0x23e/0x2f0
     [<ffffffff8114d214>] finish_open+0x34/0x50
     [<ffffffff8115e122>] do_last.isra.62+0x2d2/0xc50
     [<ffffffff8115eb58>] path_openat.isra.63+0xb8/0x4d0
     [<ffffffff81115a8e>] ? might_fault+0x4e/0xa0
     [<ffffffff8115f4f0>] do_filp_open+0x40/0x90
     [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
     [<ffffffff8116db85>] ? __alloc_fd+0xa5/0x1f0
     [<ffffffff8114e45f>] do_sys_open+0xef/0x1d0
     [<ffffffff8114e559>] SyS_open+0x19/0x20
     [<ffffffff813cff16>] system_call_fastpath+0x1a/0x1f
    Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5
    a4 07 00 44 89
    RIP  [<ffffffff8118b188>] __blkdev_get+0x28/0x450
     RSP <ffff88023e47dbd8>
    CR2: 00000000000002b4
    ---[ end trace bb7f32dbf02398dc ]---
    
    The brd change should be backported to stable kernels starting with 2.6.25.
    The loop change should be backported to stable kernels starting with 2.6.22.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 869d4e7f52ada7136161a9ac343ecc000a77f46d
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Tue Oct 8 14:36:41 2013 -0400

    block: fix race between request completion and timeout handling
    
    commit 4912aa6c11e6a5d910264deedbec2075c6f1bb73 upstream.
    
    crocode i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma dca be2net sg ses enclosure ext4 mbcache jbd2 sd_mod crc_t10dif ahci megaraid_sas(U) dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
    
    Pid: 491, comm: scsi_eh_0 Tainted: G        W  ----------------   2.6.32-220.13.1.el6.x86_64 #1 IBM  -[8722PAX]-/00D1461
    RIP: 0010:[<ffffffff8124e424>]  [<ffffffff8124e424>] blk_requeue_request+0x94/0xa0
    RSP: 0018:ffff881057eefd60  EFLAGS: 00010012
    RAX: ffff881d99e3e8a8 RBX: ffff881d99e3e780 RCX: ffff881d99e3e8a8
    RDX: ffff881d99e3e8a8 RSI: ffff881d99e3e780 RDI: ffff881d99e3e780
    RBP: ffff881057eefd80 R08: ffff881057eefe90 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff881057f92338
    R13: 0000000000000000 R14: ffff881057f92338 R15: ffff883058188000
    FS:  0000000000000000(0000) GS:ffff880040200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000000006d3ec0 CR3: 000000302cd7d000 CR4: 00000000000406b0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process scsi_eh_0 (pid: 491, threadinfo ffff881057eee000, task ffff881057e29540)
    Stack:
     0000000000001057 0000000000000286 ffff8810275efdc0 ffff881057f16000
    <0> ffff881057eefdd0 ffffffff81362323 ffff881057eefe20 ffffffff8135f393
    <0> ffff881057e29af8 ffff8810275efdc0 ffff881057eefe78 ffff881057eefe90
    Call Trace:
     [<ffffffff81362323>] __scsi_queue_insert+0xa3/0x150
     [<ffffffff8135f393>] ? scsi_eh_ready_devs+0x5e3/0x850
     [<ffffffff81362a23>] scsi_queue_insert+0x13/0x20
     [<ffffffff8135e4d4>] scsi_eh_flush_done_q+0x104/0x160
     [<ffffffff8135fb6b>] scsi_error_handler+0x35b/0x660
     [<ffffffff8135f810>] ? scsi_error_handler+0x0/0x660
     [<ffffffff810908c6>] kthread+0x96/0xa0
     [<ffffffff8100c14a>] child_rip+0xa/0x20
     [<ffffffff81090830>] ? kthread+0x0/0xa0
     [<ffffffff8100c140>] ? child_rip+0x0/0x20
    Code: 00 00 eb d1 4c 8b 2d 3c 8f 97 00 4d 85 ed 74 bf 49 8b 45 00 49 83 c5 08 48 89 de 4c 89 e7 ff d0 49 8b 45 00 48 85 c0 75 eb eb a4 <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
    RIP  [<ffffffff8124e424>] blk_requeue_request+0x94/0xa0
     RSP <ffff881057eefd60>
    
    The RIP is this line:
            BUG_ON(blk_queued_rq(rq));
    
    After digging through the code, I think there may be a race between the
    request completion and the timer handler running.
    
    A timer is started for each request put on the device's queue (see
    blk_start_request->blk_add_timer).  If the request does not complete
    before the timer expires, the timer handler (blk_rq_timed_out_timer)
    will mark the request complete atomically:
    
    static inline int blk_mark_rq_complete(struct request *rq)
    {
            return test_and_set_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags);
    }
    
    and then call blk_rq_timed_out.  The latter function will call
    scsi_times_out, which will return one of BLK_EH_HANDLED,
    BLK_EH_RESET_TIMER or BLK_EH_NOT_HANDLED.  If BLK_EH_RESET_TIMER is
    returned, blk_clear_rq_complete is called, and blk_add_timer is again
    called to simply wait longer for the request to complete.
    
    Now, if the request happens to complete while this is going on, what
    happens?  Given that we know the completion handler will bail if it
    finds the REQ_ATOM_COMPLETE bit set, we need to focus on the completion
    handler running after that bit is cleared.  So, from the above
    paragraph, after the call to blk_clear_rq_complete.  If the completion
    sets REQ_ATOM_COMPLETE before the BUG_ON in blk_add_timer, we go boom
    there (I haven't seen this in the cores).  Next, if we get the
    completion before the call to list_add_tail, then the timer will
    eventually fire for an old req, which may either be freed or reallocated
    (there is evidence that this might be the case).  Finally, if the
    completion comes in *after* the addition to the timeout list, I think
    it's harmless.  The request will be removed from the timeout list,
    req_atom_complete will be set, and all will be well.
    
    This will only actually explain the coredumps *IF* the request
    structure was freed, reallocated *and* queued before the error handler
    thread had a chance to process it.  That is possible, but it may make
    sense to keep digging for another race.  I think that if this is what
    was happening, we would see other instances of this problem showing up
    as null pointer or garbage pointer dereferences, for example when the
    request structure was not re-used.  It looks like we actually do run
    into that situation in other reports.
    
    This patch moves the BUG_ON(test_bit(REQ_ATOM_COMPLETE,
    &req->atomic_flags)); from blk_add_timer to the only caller that could
    trip over it (blk_start_request).  It then inverts the calls to
    blk_clear_rq_complete and blk_add_timer in blk_rq_timed_out to address
    the race.  I've boot tested this patch, but nothing more.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Acked-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 598f412c2f62635b20b110e46d5c4eba2fb96834
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Nov 15 10:40:38 2013 +0100

    hwmon: (lm90) Fix max6696 alarm handling
    
    commit e41fae2b1ed8c78283d73651cd65be0228c0dd1c upstream.
    
    Bit 2 of status register 2 on MAX6696 (external diode 2 open)
    sets ALERT; the bit thus has to be listed in alert_alarms.
    Also display a message in the alert handler if the condition
    is encountered.
    
    Even though not all overtemperature conditions cause ALERT
    to be set, we should not ignore them in the alert handler.
    Display messages for all out-of-range conditions.
    
    Reported-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cce2a8756944a83dee2b687800bcca369ecbbed
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date:   Fri Nov 15 13:14:12 2013 -0800

    arm/arm64: KVM: Fix hyp mappings of vmalloc regions
    
    commit 40c2729bab48e2832b17c1fa8af9db60e776131b upstream.
    
    Using virt_to_phys on percpu mappings is horribly wrong as it may be
    backed by vmalloc.  Introduce kvm_kaddr_to_phys which translates both
    types of valid kernel addresses to the corresponding physical address.
    
    At the same time resolves a typing issue where we were storing the
    physical address as a 32 bit unsigned long (on arm), truncating the
    physical address for addresses above the 4GB limit.  This caused
    breakage on Keystone.
    
    Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac18077a4150ab4ecddea135e466c55cc6c551ab
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe78c20faafde229631b0402ef9fdfbc75277903
Author: Kevin Hao <haokexin@gmail.com>
Date:   Wed Oct 23 20:58:16 2013 +0800

    ftrace/x86: skip over the breakpoint for ftrace caller
    
    commit ab4ead02ec235d706d0611d8741964628291237e upstream.
    
    In commit 8a4d0a687a59 "ftrace: Use breakpoint method to update ftrace
    caller", we choose to use breakpoint method to update the ftrace
    caller. But we also need to skip over the breakpoint in function
    ftrace_int3_handler() for them. Otherwise weird things would happen.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5f92a134b69faeffa0e1a811f01a48d686a4e97
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Oct 31 23:05:24 2013 +0100

    KVM: x86: fix emulation of "movzbl %bpl, %eax"
    
    commit daf727225b8abfdfe424716abac3d15a3ac5626a upstream.
    
    When I was looking at RHEL5.9's failure to start with
    unrestricted_guest=0/emulate_invalid_guest_state=1, I got it working with a
    slightly older tree than kvm.git.  I now debugged the remaining failure,
    which was introduced by commit 660696d1 (KVM: X86 emulator: fix
    source operand decoding for 8bit mov[zs]x instructions, 2013-04-24)
    introduced a similar mis-emulation to the one in commit 8acb4207 (KVM:
    fix sil/dil/bpl/spl in the mod/rm fields, 2013-05-30).  The incorrect
    decoding occurs in 8-bit movzx/movsx instructions whose 8-bit operand
    is sil/dil/bpl/spl.
    
    Needless to say, "movzbl %bpl, %eax" does occur in RHEL5.9's decompression
    prolog, just a handful of instructions before finally giving control to
    the decompressed vmlinux and getting out of the invalid guest state.
    
    Because OpMem8 bypasses decode_modrm, the same handling of the REX prefix
    must be applied to OpMem8.
    
    Reported-by: Michele Baldessari <michele@redhat.com>
    Cc: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4673c4343e86c0b74d79e8b02eafa0da263989a
Author: Thomas Renninger <trenn@suse.de>
Date:   Tue Nov 12 17:39:43 2013 +0100

    x86/microcode/amd: Tone down printk(), don't treat a missing firmware file as an error
    
    commit 11f918d3e2d3861b6931e97b3aa778e4984935aa upstream.
    
    Do it the same way as done in microcode_intel.c: use pr_debug()
    for missing firmware files.
    
    There seem to be CPUs out there for which no microcode update
    has been submitted to kernel-firmware repo yet resulting in
    scary sounding error messages in dmesg:
    
      microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin
    
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Acked-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7c1ad19d74ccb254332c7b7d667998f1c26b64b
Author: Christoph Hellwig <hch@infradead.org>
Date:   Mon Nov 18 05:07:47 2013 -0800

    nfsd: make sure to balance get/put_write_access
    
    commit 987da4791052fa298b7cfcde4dea9f6f2bbc786b upstream.
    
    Use a straight goto error label style in nfsd_setattr to make sure
    we always do the put_write_access call after we got it earlier.
    
    Note that the we have been failing to do that in the case
    nfsd_break_lease() returns an error, a bug introduced into 2.6.38 with
    6a76bebefe15d9a08864f824d7f8d5beaf37c997 "nfsd4: break lease on nfsd
    setattr".
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b26be14b8e496c6fa14b53ba3390b56a5988df8a
Author: Christoph Hellwig <hch@infradead.org>
Date:   Mon Nov 18 05:07:30 2013 -0800

    nfsd: split up nfsd_setattr
    
    commit 818e5a22e907fbae75e9c1fd78233baec9fa64b6 upstream.
    
    Split out two helpers to make the code more readable and easier to verify
    for correctness.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b7330f9057949e8c5df82df8a76068d0129e778
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Sep 13 11:08:45 2013 -0400

    nfsd: return better errors to exportfs
    
    commit 427d6c6646d868fbd3094e7e2e1644d480cd9204 upstream.
    
    Someone noticed exportfs happily accepted exports that would later be
    rejected when mountd tried to give them to the kernel.  Fix this.
    
    This is a regression from 4c1e1b34d5c800ad3ac9a7e2805b0bea70ad2278
    "nfsd: Store ex_anon_uid and ex_anon_gid as kuids and kgids".
    
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Reported-by: Yin.JianHong <jiyin@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1311157d8407d16b8543c2286f0e95251ca04fe8
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Oct 28 14:57:12 2013 -0400

    NFSv4: Fix state reference counting in _nfs4_opendata_reclaim_to_nfs4_state
    
    commit d49f042aeec99c5f87160bb52dd52088b1051311 upstream.
    
    Currently, if the call to nfs_refresh_inode fails, then we end up leaking
    a reference count, due to the call to nfs4_get_open_state.
    While we're at it, replace nfs4_get_open_state with a simple call to
    atomic_inc(); there is no need to do a full lookup of the struct nfs_state
    since it is passed as an argument in the struct nfs4_opendata, and
    is already assigned to the variable 'state'.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 231817ee68a9640d91ef34ce12c4d67b38f17ed8
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Mon Oct 21 13:10:13 2013 -0400

    NFSv4: don't reprocess cached open CLAIM_PREVIOUS
    
    commit d2bfda2e7aa036f90ccea610a657064b1e267913 upstream.
    
    Cached opens have already been handled by _nfs4_opendata_reclaim_to_nfs4_state
    and can safely skip being reprocessed, but must still call update_open_stateid
    to make sure that all active fmodes are recovered.
    
    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5178adbeda8c532361fd22a6dff3bf699ab8b13
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Mon Oct 21 13:10:11 2013 -0400

    NFSv4: don't fail on missing fattr in open recover
    
    commit a43ec98b72aae3e330f0673438f58316c3769b84 upstream.
    
    This is an unneeded check that could cause the client to fail to recover
    opens.
    
    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84febe04c528ef627da6962169e7ae324a0a2b99
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Mon Oct 21 13:10:10 2013 -0400

    NFSv4: fix NULL dereference in open recover
    
    commit f494a6071d31e3294a3b51ad7a3684f983953f9f upstream.
    
    _nfs4_opendata_reclaim_to_nfs4_state doesn't expect to see a cached
    open CLAIM_PREVIOUS, but this can happen. An example is when there are
    RDWR openers and RDONLY openers on a delegation stateid. The recovery
    path will first try an open CLAIM_PREVIOUS for the RDWR openers, this
    marks the delegation as not needing RECLAIM anymore, so the open
    CLAIM_PREVIOUS for the RDONLY openers will not actually send an rpc.
    
    The NULL dereference is due to _nfs4_opendata_reclaim_to_nfs4_state
    returning PTR_ERR(rpc_status) when !rpc_done. When the open is
    cached, rpc_done == 0 and rpc_status == 0, thus
    _nfs4_opendata_reclaim_to_nfs4_state returns NULL - this is unexpected
    by callers of nfs4_opendata_to_nfs4_state().
    
    This can be reproduced easily by opening the same file two times on an
    NFSv4.0 mount with delegations enabled, once as RDWR and once as RDONLY then
    sleeping for a long time.  While the files are held open, kick off state
    recovery and this NULL dereference will be hit every time.
    
    An example OOPS:
    
    [   65.003602] BUG: unable to handle kernel NULL pointer dereference at 00000000
    00000030
    [   65.005312] IP: [<ffffffffa037d6ee>] __nfs4_close+0x1e/0x160 [nfsv4]
    [   65.006820] PGD 7b0ea067 PUD 791ff067 PMD 0
    [   65.008075] Oops: 0000 [#1] SMP
    [   65.008802] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache
    snd_ens1371 gameport nfsd snd_rawmidi snd_ac97_codec ac97_bus btusb snd_seq snd
    _seq_device snd_pcm ppdev bluetooth auth_rpcgss coretemp snd_page_alloc crc32_pc
    lmul crc32c_intel ghash_clmulni_intel microcode rfkill nfs_acl vmw_balloon serio
    _raw snd_timer lockd parport_pc e1000 snd soundcore parport i2c_piix4 shpchp vmw
    _vmci sunrpc ata_generic mperf pata_acpi mptspi vmwgfx ttm scsi_transport_spi dr
    m mptscsih mptbase i2c_core
    [   65.018684] CPU: 0 PID: 473 Comm: 192.168.10.85-m Not tainted 3.11.2-201.fc19
    .x86_64 #1
    [   65.020113] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
    Reference Platform, BIOS 6.00 07/31/2013
    [   65.022012] task: ffff88003707e320 ti: ffff88007b906000 task.ti: ffff88007b906000
    [   65.023414] RIP: 0010:[<ffffffffa037d6ee>]  [<ffffffffa037d6ee>] __nfs4_close+0x1e/0x160 [nfsv4]
    [   65.025079] RSP: 0018:ffff88007b907d10  EFLAGS: 00010246
    [   65.026042] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [   65.027321] RDX: 0000000000000050 RSI: 0000000000000001 RDI: 0000000000000000
    [   65.028691] RBP: ffff88007b907d38 R08: 0000000000016f60 R09: 0000000000000000
    [   65.029990] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
    [   65.031295] R13: 0000000000000050 R14: 0000000000000000 R15: 0000000000000001
    [   65.032527] FS:  0000000000000000(0000) GS:ffff88007f600000(0000) knlGS:0000000000000000
    [   65.033981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   65.035177] CR2: 0000000000000030 CR3: 000000007b27f000 CR4: 00000000000407f0
    [   65.036568] Stack:
    [   65.037011]  0000000000000000 0000000000000001 ffff88007b907d90 ffff88007a880220
    [   65.038472]  ffff88007b768de8 ffff88007b907d48 ffffffffa037e4a5 ffff88007b907d80
    [   65.039935]  ffffffffa036a6c8 ffff880037020e40 ffff88007a880000 ffff880037020e40
    [   65.041468] Call Trace:
    [   65.042050]  [<ffffffffa037e4a5>] nfs4_close_state+0x15/0x20 [nfsv4]
    [   65.043209]  [<ffffffffa036a6c8>] nfs4_open_recover_helper+0x148/0x1f0 [nfsv4]
    [   65.044529]  [<ffffffffa036a886>] nfs4_open_recover+0x116/0x150 [nfsv4]
    [   65.045730]  [<ffffffffa036d98d>] nfs4_open_reclaim+0xad/0x150 [nfsv4]
    [   65.046905]  [<ffffffffa037d979>] nfs4_do_reclaim+0x149/0x5f0 [nfsv4]
    [   65.048071]  [<ffffffffa037e1dc>] nfs4_run_state_manager+0x3bc/0x670 [nfsv4]
    [   65.049436]  [<ffffffffa037de20>] ? nfs4_do_reclaim+0x5f0/0x5f0 [nfsv4]
    [   65.050686]  [<ffffffffa037de20>] ? nfs4_do_reclaim+0x5f0/0x5f0 [nfsv4]
    [   65.051943]  [<ffffffff81088640>] kthread+0xc0/0xd0
    [   65.052831]  [<ffffffff81088580>] ? insert_kthread_work+0x40/0x40
    [   65.054697]  [<ffffffff8165686c>] ret_from_fork+0x7c/0xb0
    [   65.056396]  [<ffffffff81088580>] ? insert_kthread_work+0x40/0x40
    [   65.058208] Code: 5c 41 5d 5d c3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 89 f7 41 56 41 89 ce 41 55 41 89 d5 41 54 53 48 89 fb <4c> 8b 67 30 f0 41 ff 44 24 44 49 8d 7c 24 40 e8 0e 0a 2d e1 44
    [   65.065225] RIP  [<ffffffffa037d6ee>] __nfs4_close+0x1e/0x160 [nfsv4]
    [   65.067175]  RSP <ffff88007b907d10>
    [   65.068570] CR2: 0000000000000030
    [   65.070098] ---[ end trace 0d1fe4f5c7dd6f8b ]---
    
    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55fce163b8367ce78c163f0f63a8326ea266c09f
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Oct 1 14:24:58 2013 -0400

    NFSv4: Fix a use-after-free situation in _nfs4_proc_getlk()
    
    commit a6f951ddbdfb7bd87d31a44f61abe202ed6ce57f upstream.
    
    In nfs4_proc_getlk(), when some error causes a retry of the call to
    _nfs4_proc_getlk(), we can end up with Oopses of the form
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000134
     IP: [<ffffffff8165270e>] _raw_spin_lock+0xe/0x30
    <snip>
     Call Trace:
      [<ffffffff812f287d>] _atomic_dec_and_lock+0x4d/0x70
      [<ffffffffa053c4f2>] nfs4_put_lock_state+0x32/0xb0 [nfsv4]
      [<ffffffffa053c585>] nfs4_fl_release_lock+0x15/0x20 [nfsv4]
      [<ffffffffa0522c06>] _nfs4_proc_getlk.isra.40+0x146/0x170 [nfsv4]
      [<ffffffffa052ad99>] nfs4_proc_lock+0x399/0x5a0 [nfsv4]
    
    The problem is that we don't clear the request->fl_ops after the first
    try and so when we retry, nfs4_set_lock_state() exits early without
    setting the lock stateid.
    Regression introduced by commit 70cc6487a4e08b8698c0e2ec935fb48d10490162
    (locks: make ->lock release private data before returning in GETLK case)
    
    Reported-by: Weston Andros Adamson <dros@netapp.com>
    Reported-by: Jorge Mora <mora@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bc7e35d3470bf24c7640984bbfe20afd804afdb
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 22 08:06:36 2013 +0100

    ALSA: hda - Provide missing pin configs for VAIO with ALC260
    
    commit d08c5ef2a039393eaf2ab2152db5f07790fa0f40 upstream.
    
    Some models (or maybe depending on BIOS version) of Sony VAIO with
    ALC260 give no proper pin configurations as default, resulting in the
    non-working speaker, etc.  Just provide the whole pin configurations
    via a fixup.
    
    Reported-by: Matthew Markus <mmarkus@hearit.co>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55b13703da85a79c38b3fe986f777838846d1623
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Thu Nov 21 14:12:59 2013 +0100

    ALSA: hda - Add headset quirk for Dell Inspiron 3135
    
    commit b8362e70cbbb397db50939bc4c7c78dc3246c3eb upstream.
    
    BugLink: https://bugs.launchpad.net/bugs/1253636
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a020c697a1bd12ed3c1ea1f9435955174da879b2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 21 09:12:52 2013 +0100

    ALSA: hda - Fix the headphone jack detection on Sony VAIO TX
    
    commit 0f5a5b8515472a0219768423226b58228001e3d5 upstream.
    
    BIOS sets MISC_NO_PRESENCE bit wrongly to the pin config on NID 0x0f.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3bd14e68a1d4eaabbac84a3a28288a3bf13f9f6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 20 12:15:07 2013 +0100

    ALSA: hda - Fix unbalanced runtime PM notification at resume
    
    commit 0fc28fc030a85aa3d6d14e9e9fca0c8237c9ffb5 upstream.
    
    When a codec is resumed, it keeps the power on while the resuming
    phase via hda_keep_power_on(), then turns down via
    snd_hda_power_down().  At that point, snd_hda_power_down() notifies
    the power down to the controller, and this may confuse the refcount if
    the codec was already powered up before the resume.
    
    In the end result, the controller goes to runtime suspend even before
    the codec is kicked off to the power save, and the communication
    stalls happens.
    
    The fix is to add the power-up notification together with
    hda_keep_power_on(), and clears the flag appropriately.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7088cd2da7489d71a6b5d569899f8af3f85247c4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 16:58:10 2013 +0100

    ALSA: hda - Don't clear the power state at snd_hda_codec_reset()
    
    commit d183b4fc463489b6bbe05c99afa0257a6fe578eb upstream.
    
    snd_hda_codec_reset() is called either in resetting the whole setup at
    error paths or hwdep clear/reconfig sysfs triggers.  But all of these
    don't assume that the power has to be off, rather they want to keep
    the power state unchanged (e.g. reconfig_codec() calls the power
    up/down by itself).  Thus, unconditionally clearing the power state in
    snd_hda_codec_reset() leads to the inconsistency, confuses the further
    operation.   This patch gets rid of the lines doing that bad thing.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5c32fe75ce821a7a0ae1dd3f89c97f50a8a0304
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 09:39:08 2013 +0100

    ALSA: hda - Don't turn off EAPD for headphone on Lenovo N100
    
    commit 7a3e6107f94344e65c35bfe62de6c096a7b48965 upstream.
    
    The only EAPD on AD1986A is on NID 0x1b where usually the speaker.
    But this doesn't control only the speaker amp but may influence on all
    outputs, e.g. Lenovo N100 laptop seems to have this issue.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 320f9078dbc4f9f71c79084d77cfe4c03aaaf328
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 12 11:36:00 2013 +0100

    ALSA: hda - Check keep_eapd_on before inv_eapd
    
    commit 468ac413045af1e0e4d1272291bed6878f248a69 upstream.
    
    We don't change the EAPD bit in set_pin_eapd() if keep_eapd_on flag is
    set by the codec driver and enable is false.  But, we also apply the
    flipping of enable value according to inv_eapd flag in the same
    function, and this confused the former check, handled as if it's
    turned ON.  The inverted EAPD check must be applied after keep_eapd_on
    check, instead.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6ebcc4a440d9d8243ce33ed6c95235125fe1a80
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Tue Nov 12 11:10:57 2013 +0100

    ALSA: hda - Fix Line Out automute on Realtek multifunction jacks
    
    commit 5959a6bc1124211a359525d209005abc07b0197b upstream.
    
    In case there is both a multifunction headset jack and a Line Out
    jack, automuting was not working properly from the Line Out jack.
    This patch fixes that issue.
    
    BugLink: https://bugs.launchpad.net/bugs/1250377
    Tested-by: Cyrus Lien <cyrus.lien@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 705f5ab4855df0dee9abd526b170cb43632add72
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 7 07:29:30 2013 +0100

    ALSA: hda - Add pincfg fixup for ASUS W5A
    
    commit 487a588d09db0d6508261867df208d8bdc718251 upstream.
    
    BIOS on ASUS W5A laptop with ALC880 codec doesn't provide any pin
    configurations, so we have to set up all pins manually.
    
    Reported-and-tested-by: nb <nb@dagami.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc788a78ccf8e4a4862e9dd7f1faa4150583a91b
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca4c12c0cf1d0efb5e7ffecf31cb17f95e1e77df
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Nov 6 10:50:44 2013 +0100

    ALSA: hda - Make sure mute LEDs stay on during runtime suspend (Realtek)
    
    commit d5b6b65e75ce607c2734227524e11574317a1c1a upstream.
    
    Some HP machines with Realtek codecs have mute LEDs connected to VREF pins.
    However when these go into runtime suspend, the pin powers down and its
    pin control is disabled, thus disabling the LED too.
    
    This patch fixes that issue by making sure that the pin stays in D0 with
    correct pin control.
    
    BugLink: https://bugs.launchpad.net/bugs/1248465
    Tested-by: Franz Hsieh <franz.hsieh@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0009160a1b27a03d11ba007c542474aaba0b5380
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Nov 4 18:21:08 2013 +0100

    ALSA: hda - Enable SPDIF for Acer TravelMate 6293
    
    commit 24eff328f65c8ef352c90b6adb7c2f39eb94205d upstream.
    
    BIOS on Acer TravelMate 6293 doesn't set up the SPDIF output pin
    correctly as default, so enable it via a fixup entry.
    
    Reported-and-tested-by: Hagen Heiduck <heiduck.suse@fmail.postpro.net>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51f7512087067c0ba31bd5ad4bad5258fbd9b44c
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Oct 24 11:35:18 2013 +0200

    ALSA: hda - Add support of ALC255 codecs
    
    commit 1d04c9de5c76df113e4af7120feb53c628b5efcc upstream.
    
    It's just another variant of ALC269 & co.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 737d967e6b6c5f812e0c141e8ecb1207e5fd8b38
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 12 08:06:20 2013 +0100

    ALSA: msnd: Avoid duplicated driver name
    
    commit 092f9cd16aac7d054af1755c945f37c1b33399e6 upstream.
    
    msnd_pinnacle.c is used for both snd-msnd-pinnacle and
    snd-msnd-classic drivers, and both should have different driver
    names.  Using the same driver name results in the sysfs warning for
    duplicated entries like
     kobject: 'msnd-pinnacle.7' (cec33408): kobject_release, parent   (null) (delayed)
     kobject: 'msnd-pinnacle' (cecd4980): kobject_release, parent cf3ad9b0 (delayed)
     ------------[ cut here ]------------
     WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:486 sysfs_warn_dup+0x7d/0xa0()
     sysfs: cannot create duplicate filename '/bus/isa/drivers/msnd-pinnacle'
     ......
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86e6de789cfeb2bb6c532281e16a478d797f3598
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Thu Nov 7 10:08:22 2013 +0100

    ALSA: compress: fix drain calls blocking other compress functions (v6)
    
    commit f44f2a5417b2968a8724b352cc0b2545a6bcb1f4 upstream.
    
    The drain and drain_notify callback were blocked by low level driver
    until the draining was complete. Due to this being invoked with big
    fat mutex held, others ops like reading timestamp, calling pause, drop
    were blocked.
    
    So to fix this we add a new snd_compr_drain_notify() API. This would
    be required to be invoked by low level driver when drain or partial
    drain has been completed by the DSP. Thus we make the drain and
    partial_drain callback as non blocking and driver returns immediately
    after notifying DSP.  The waiting is done while releasing the lock so
    that other ops can go ahead.
    
    [ The commit 917f4b5cba78 was wrongly applied from the preliminary
      patch.  This commit corrects to the final version.
      Sorry for inconvenience!  -- tiwai ]
    
    Signed-off-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 16442d4ff3014c84008266feee1e36befd84c8c3
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Thu Oct 24 16:37:31 2013 +0530

    ALSA: compress: fix drain calls blocking other compress functions
    
    commit 917f4b5cba78980a527098a910d94139d3e82c8d upstream.
    
    The drain and drain_notify callback were blocked by low level driver untill the
    draining was complete. Due to this being invoked with big fat mutex held, others
    ops like reading timestamp, calling pause, drop were blocked.
    
    So to fix this we add a new snd_compr_drain_notify() API. This would be required
    to be invoked by low level driver when drain or partial drain has been completed
    by the DSP. Thus we make the drain and partial_drain callback as non blocking
    and driver returns immediately after notifying DSP.
    The waiting is done while relasing the lock so that other ops can go ahead.
    
    Signed-off-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 75dab4710ba28b127cd5587b44ea5668fcde9a61
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 28 11:24:23 2013 +0100

    ALSA: 6fire: Fix probe of multiple cards
    
    commit 9b389a8a022110b4bc055a19b888283544d9eba6 upstream.
    
    The probe code of snd-usb-6fire driver overrides the devices[] pointer
    wrongly without checking whether it's already occupied or not.  This
    would screw up the device disconnection later.
    
    Spotted by coverity CID 141423.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d389d610b143d487e50fe898e0ee9d329c279a1b
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Nov 12 15:11:17 2013 -0800

    exec/ptrace: fix get_dumpable() incorrect tests
    
    commit d049f74f2dbe71354d43d393ac3a188947811348 upstream.
    
    The get_dumpable() return value is not boolean.  Most users of the
    function actually want to be testing for non-SUID_DUMP_USER(1) rather than
    SUID_DUMP_DISABLE(0).  The SUID_DUMP_ROOT(2) is also considered a
    protected state.  Almost all places did this correctly, excepting the two
    places fixed in this patch.
    
    Wrong logic:
        if (dumpable == SUID_DUMP_DISABLE) { /* be protective */ }
            or
        if (dumpable == 0) { /* be protective */ }
            or
        if (!dumpable) { /* be protective */ }
    
    Correct logic:
        if (dumpable != SUID_DUMP_USER) { /* be protective */ }
            or
        if (dumpable != 1) { /* be protective */ }
    
    Without this patch, if the system had set the sysctl fs/suid_dumpable=2, a
    user was able to ptrace attach to processes that had dropped privileges to
    that user.  (This may have been partially mitigated if Yama was enabled.)
    
    The macros have been moved into the file that declares get/set_dumpable(),
    which means things like the ia64 code can see them too.
    
    CVE-2013-2929
    
    Reported-by: Vasily Kulikov <segoon@openwall.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: "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 8bcee197d648d07ad81a9322ea93de85ab1719eb
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date:   Thu Oct 17 07:34:02 2013 -0400

    Revert "ima: policy for RAMFS"
    
    commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
    
    This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
    
    Everything in the initramfs should be measured and appraised,
    but until the initramfs has extended attribute support, at
    least measured.
    
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac600ac47b4b44af06c3518f6754f91bc4e89a47
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Oct 31 11:23:57 2013 +0100

    rt2x00: fix HT TX descriptor settings regression
    
    commit 3d8bfe141be8e5c21261fc63da8e7964d44f2645 upstream.
    
    Since:
    
    commit 36323f817af0376c78612cfdab714b0feb05fea5
    Author: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
    Date:   Mon Jul 23 21:33:42 2012 +0200
    
        mac80211: move TX station pointer and restructure TX
    
    we do not pass sta pointer to rt2x00queue_create_tx_descriptor_ht(),
    hence we do not correctly set station WCID and AMPDU density parameters.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e11a27ff570fbebd37fcca1a329966194b46879
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Thu Oct 3 20:00:40 2013 +0200

    rt2x00: rt2800lib: fix VGC adjustment for RT5592
    
    commit 0beb1bbf19c72f17809e42b8f33522a55c2cc18c upstream.
    
    In commit 3d81535ea5940446510a8a5cee1c6ad23c90c753
    (rt2800: 5592: add chip specific vgc calculations)
    the rt2800_link_tuner function has been modified to
    adjust VGC level for the RT5592 chipset.
    
    On the RT5592 chipset, the VGC level must be adjusted
    only if rssi is greater than -65. However the current
    code adjusts the VGC value by 0x10 regardless of the
    actual chipset if the rssi value is between -80 and
    -65.
    
    Fix the broken behaviour by reordering the if-else
    statements.
    
    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3e4f5f80f95f69e98624e97eaf2b9c2a6238288
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:   Tue Oct 15 14:31:12 2013 +0200

    rt2x00: check if device is still available on rt2x00mac_flush()
    
    commit 5671ab05cf2a579218985ef56595387932d78ee4 upstream.
    
    Fix random kernel panic with below messages when remove dongle.
    
    [ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250
    [ 2212.355527] IP: [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
    [ 2212.355599] PGD 0
    [ 2212.355626] Oops: 0000 [#1] SMP
    [ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211]
    [ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3
    [ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013
    [ 2212.356319] task: ffff880212f687c0 ti: ffff880212f66000 task.ti: ffff880212f66000
    [ 2212.356392] RIP: 0010:[<ffffffffa02667f2>]  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
    [ 2212.356481] RSP: 0018:ffff880212f67750  EFLAGS: 00010202
    [ 2212.356519] RAX: 000000000000000c RBX: 000000000000000c RCX: 0000000000000293
    [ 2212.356568] RDX: ffff8801f4dc219a RSI: 0000000000000000 RDI: 0000000000000240
    [ 2212.356617] RBP: ffff880212f67778 R08: ffffffffa02667e0 R09: 0000000000000002
    [ 2212.356665] R10: 0001f95254ab4b40 R11: ffff880212f675be R12: ffff8801f4dc2150
    [ 2212.356712] R13: 0000000000000000 R14: ffffffffa02667e0 R15: 000000000000000d
    [ 2212.356761] FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
    [ 2212.356813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 2212.356852] CR2: 0000000000000250 CR3: 0000000001a0c000 CR4: 00000000001407f0
    [ 2212.356899] Stack:
    [ 2212.356917]  000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0
    [ 2212.356980]  000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a
    [ 2212.357038]  ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800
    [ 2212.357099] Call Trace:
    [ 2212.357122]  [<ffffffffa02667e0>] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb]
    [ 2212.357174]  [<ffffffffa03a31ad>] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib]
    [ 2212.357244]  [<ffffffffa026701c>] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb]
    [ 2212.357314]  [<ffffffffa03a3682>] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib]
    [ 2212.357386]  [<ffffffffa03a2930>] rt2x00mac_flush+0x30/0x70 [rt2x00lib]
    [ 2212.357470]  [<ffffffffa04edded>] ieee80211_flush_queues+0xbd/0x140 [mac80211]
    [ 2212.357555]  [<ffffffffa0502e52>] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211]
    [ 2212.357645]  [<ffffffffa0506da3>] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211]
    [ 2212.357718]  [<ffffffff8108b17c>] ? try_to_wake_up+0xec/0x290
    [ 2212.357788]  [<ffffffffa04dbd18>] ieee80211_deauth+0x18/0x20 [mac80211]
    [ 2212.357872]  [<ffffffffa0418ddc>] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211]
    [ 2212.357913]  [<ffffffffa041907c>] cfg80211_mlme_down+0x5c/0x60 [cfg80211]
    [ 2212.357962]  [<ffffffffa041cd18>] cfg80211_disconnect+0x188/0x1a0 [cfg80211]
    [ 2212.358014]  [<ffffffffa04013bc>] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211]
    [ 2212.358067]  [<ffffffffa03f8954>] cfg80211_leave+0xc4/0xe0 [cfg80211]
    [ 2212.358124]  [<ffffffffa03f8d1b>] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211]
    [ 2212.358177]  [<ffffffff815140f8>] ? inetdev_event+0x38/0x510
    [ 2212.358217]  [<ffffffff81085a94>] ? __wake_up+0x44/0x50
    [ 2212.358254]  [<ffffffff8155995c>] notifier_call_chain+0x4c/0x70
    [ 2212.358293]  [<ffffffff81081156>] raw_notifier_call_chain+0x16/0x20
    [ 2212.358361]  [<ffffffff814b6dd5>] call_netdevice_notifiers_info+0x35/0x60
    [ 2212.358429]  [<ffffffff814b6ec9>] __dev_close_many+0x49/0xd0
    [ 2212.358487]  [<ffffffff814b7028>] dev_close_many+0x88/0x100
    [ 2212.358546]  [<ffffffff814b8150>] rollback_registered_many+0xb0/0x220
    [ 2212.358612]  [<ffffffff814b8319>] unregister_netdevice_many+0x19/0x60
    [ 2212.358694]  [<ffffffffa04d8eb2>] ieee80211_remove_interfaces+0x112/0x190 [mac80211]
    [ 2212.358791]  [<ffffffffa04c585f>] ieee80211_unregister_hw+0x4f/0x100 [mac80211]
    [ 2212.361994]  [<ffffffffa03a1221>] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib]
    [ 2212.365240]  [<ffffffffa0266e2e>] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb]
    [ 2212.368470]  [<ffffffff81419ce4>] usb_unbind_interface+0x64/0x1c0
    [ 2212.371734]  [<ffffffff813b446f>] __device_release_driver+0x7f/0xf0
    [ 2212.374999]  [<ffffffff813b4503>] device_release_driver+0x23/0x30
    [ 2212.378131]  [<ffffffff813b3c98>] bus_remove_device+0x108/0x180
    [ 2212.381358]  [<ffffffff813b0565>] device_del+0x135/0x1d0
    [ 2212.384454]  [<ffffffff81417760>] usb_disable_device+0xb0/0x270
    [ 2212.387451]  [<ffffffff8140d9cd>] usb_disconnect+0xad/0x1d0
    [ 2212.390294]  [<ffffffff8140f6cd>] hub_thread+0x63d/0x1660
    [ 2212.393034]  [<ffffffff8107c860>] ? wake_up_atomic_t+0x30/0x30
    [ 2212.395728]  [<ffffffff8140f090>] ? hub_port_debounce+0x130/0x130
    [ 2212.398412]  [<ffffffff8107baa0>] kthread+0xc0/0xd0
    [ 2212.401058]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
    [ 2212.403639]  [<ffffffff8155de3c>] ret_from_fork+0x7c/0xb0
    [ 2212.406193]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
    [ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30
    [ 2212.414671] RIP  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
    [ 2212.417646]  RSP <ffff880212f67750>
    [ 2212.420547] CR2: 0000000000000250
    [ 2212.441024] ---[ end trace 5442918f33832bce ]---
    
    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f44b29361e380645b2fc43f760fc0c7032e5c05
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu Nov 14 21:33:15 2013 +0100

    rt2x00: fix a crash bug in the HT descriptor handling fix
    
    commit b4089d6d8e71a7293e2192025dfa507a04f661c4 upstream.
    
    Commit "rt2x00: fix HT TX descriptor settings regression"
    assumes that the control parameter to rt2x00mac_tx is always non-NULL.
    There is an internal call in rt2x00lib_bc_buffer_iter where NULL is
    passed. Fix the resulting crash by adding an initialized dummy on-stack
    ieee80211_tx_control struct.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55c00c5afd3e9adfb5f7ea556b652b3aab0f3871
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Nov 7 01:42:17 2013 +0100

    ACPI / hotplug: Do not execute "insert in progress" _OST
    
    commit 176a88d79d6b5aebabaff16734e8b3107efcaaad upstream.
    
    According to the ACPI spec (5.0, Section 6.3.5), the "Device
    insertion in progress (pending)" (0x80) _OST status code is
    reserved for the "Insertion Processing" (0x200) source event
    which is "a result of an OSPM action".  Specifically, it is not
    a notification, so that status code should not be used during
    notification processing, which unfortunately is done by
    acpi_scan_bus_device_check().
    
    For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST
    status evaluation from there (it was a mistake to put it in there
    in the first place).
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e02d0a0455b7c701586595975894539a18c9a2ba
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Nov 7 01:41:27 2013 +0100

    ACPI / hotplug: Fix handle_root_bridge_removal()
    
    commit 2441191a19039002b2c454a261fb45986df15184 upstream.
    
    It is required to do get_device() on the struct acpi_device in
    question before passing it to acpi_bus_hot_remove_device() through
    acpi_os_hotplug_execute(), because acpi_bus_hot_remove_device()
    calls acpi_scan_hot_remove() that does put_device() on that
    object.
    
    The ACPI PCI root removal routine, handle_root_bridge_removal(),
    doesn't do that, which may lead to premature freeing of the
    device object or to executing put_device() on an object that
    has been freed already.
    
    Fix this problem by making handle_root_bridge_removal() use
    get_device() as appropriate.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Toshi Kani <toshi.kani@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 602b910bb0b18c5d7887df7a05e256fac780cf49
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Wed Nov 6 09:07:10 2013 +0800

    ACPI / video: Quirk initial backlight level 0
    
    commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 upstream.
    
    Some firmware doesn't initialize initial backlight level to a proper
    value and _BQC will return 0 on first time evaluation. We used to be
    able to detect such incorrect value with our code logic, as value 0
    normally isn't a valid value in _BCL. But with the introduction of Win8,
    firmware begins to fill _BCL with values from 0 to 100, now 0 becomes
    a valid value but that value will make user's screen black. This patch
    test initial _BQC for value 0, if such a value is returned, do not use
    it.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=64031
    References: https://bugzilla.kernel.org/show_bug.cgi?id=61231
    References: https://bugzilla.kernel.org/show_bug.cgi?id=63111
    Reported-by: Qingshuai Tian <qingshuai.tian@intel.com>
    Tested-by: Aaron Lu <aaron.lu@intel.com> # on "Idealpad u330p"
    Reported-and-tested-by: <erno@iki.fi> # on "Acer Aspire V5-573G"
    Reported-and-tested-by: Kirill Tkhai <tkhai@yandex.ru> # on "HP 250 G1"
    Signed-off-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 968f56ccc37ae686e226fbd2cec9b826c4b6f7c4
Author: Puneet Kumar <puneetster@chromium.org>
Date:   Fri Nov 15 11:41:29 2013 -0800

    ACPI / EC: Ensure lock is acquired before accessing ec struct members
    
    commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream.
    
    A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug
    info and trivial code cleanup') that erroneously caused the struct member
    to be accessed before acquiring the required lock.  This change fixes
    it by ensuring the lock acquisition is done first.
    
    Found by Aaron Durbin <adurbin@chromium.org>
    
    Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup')
    References: http://crbug.com/319019
    Signed-off-by: Puneet Kumar <puneetster@chromium.org>
    Reviewed-by: Aaron Durbin <adurbin@chromium.org>
    [olof: Commit message reworded a bit]
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65b4037862eeec836fef612bbcd558ea10efe1a8
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue Nov 5 12:51:11 2013 -0500

    perf/ftrace: Fix paranoid level for enabling function tracer
    
    commit 12ae030d54ef250706da5642fc7697cc60ad0df7 upstream.
    
    The current default perf paranoid level is "1" which has
    "perf_paranoid_kernel()" return false, and giving any operations that
    use it, access to normal users. Unfortunately, this includes function
    tracing and normal users should not be allowed to enable function
    tracing by default.
    
    The proper level is defined at "-1" (full perf access), which
    "perf_paranoid_tracepoint_raw()" will only give access to. Use that
    check instead for enabling function tracing.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    CVE: CVE-2013-2930
    Fixes: ced39002f5ea ("ftrace, perf: Add support to use function tracepoint in perf")
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b81dc5b7eead5d1112c4042a41339493f71ddeb
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed Aug 28 12:01:03 2013 -0600

    PCI: Support PCIe Capability Slot registers only for ports with slots
    
    commit 6d3a1741f1e648cfbd5a0cc94477a0d5004c6f5e upstream.
    
    Previously we allowed callers to access Slot Capabilities, Status, and
    Control for Root Ports even if the Root Port did not implement a slot.
    This seems dubious because the spec only requires these registers if a
    slot is implemented.
    
    It's true that even Root Ports without slots must have *space* for these
    slot registers, because the Root Capabilities, Status, and Control
    registers are after the slot registers in the capability.  However,
    for a v1 PCIe Capability, the *semantics* of the slot registers are
    undefined unless a slot is implemented.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-By: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c944bc629b3080bb850e9a2d5797d5b602ce648
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed Aug 28 11:33:53 2013 -0600

    PCI: Remove PCIe Capability version checks
    
    commit c8b303d0206b28c4ff3aecada47108d1655ae00f upstream.
    
    Previously we relied on the PCIe r3.0, sec 7.8, spec language that says
    "For Functions that do not implement the [Link, Slot, Root] registers,
    these spaces must be hardwired to 0b," which means that for v2 PCIe
    capabilities, we don't need to check the device type at all.
    
    But it's simpler if we don't need to check the capability version at all,
    and I think the spec is explicit enough about which registers are required
    for which types that we can remove the version checks.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-By: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72a3a06c698143d5b315a2882c3ecb4c947ac5f
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Aug 27 09:54:40 2013 -0600

    PCI: Allow PCIe Capability link-related register access for switches
    
    commit d3694d4fa3f44f6a295f8ab064937c8a1549d174 upstream.
    
    Every PCIe device has a link, except Root Complex Integrated Endpoints
    and Root Complex Event Collectors.  Previously we didn't give access
    to PCIe capability link-related registers for Upstream Ports, Downstream
    Ports, and Bridges, so attempts to read PCI_EXP_LNKCTL incorrectly
    returned zero.  See PCIe spec r3.0, sec 7.8 and 1.3.2.3.
    
    Reference: http://lkml.kernel.org/r/979A8436335E3744ADCD3A9F2A2B68A52AD136BE@SJEXCHMB10.corp.ad.broadcom.com
    Reported-by: Yuval Mintz <yuvalmin@broadcom.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-By: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e895dad0a5b1db5475346d9c2ae4a92e6fefa58d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Sep 11 12:43:13 2013 +0200

    sched, idle: Fix the idle polling state logic
    
    commit ea8117478918a4734586d35ff530721b682425be upstream.
    
    Mike reported that commit 7d1a9417 ("x86: Use generic idle loop")
    regressed several workloads and caused excessive reschedule
    interrupts.
    
    The patch in question failed to notice that the x86 code had an
    inverted sense of the polling state versus the new generic code (x86:
    default polling, generic: default !polling).
    
    Fix the two prominent x86 mwait based idle drivers and introduce a few
    new generic polling helpers (fixing the wrong smp_mb__after_clear_bit
    usage).
    
    Also switch the idle routines to using tif_need_resched() which is an
    immediate TIF_NEED_RESCHED test as opposed to need_resched which will
    end up being slightly different.
    
    Reported-by: Mike Galbraith <bitbucket@online.de>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: lenb@kernel.org
    Cc: tglx@linutronix.de
    Link: http://lkml.kernel.org/n/tip-nc03imb0etuefmzybzj7sprf@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bad04d7bc7fe12a89b716f8b63d32b5735f6dd2
Author: Andy Adamson <andros@netapp.com>
Date:   Wed Aug 14 11:59:13 2013 -0400

    SUNRPC: don't map EKEYEXPIRED to EACCES in call_refreshresult
    
    commit f1ff0c27fd9987c59d707cd1a6b6c1fc3ae0a250 upstream.
    
    The NFS layer needs to know when a key has expired.
    This change also returns -EKEYEXPIRED to the application, and the informative
    "Key has expired" error message is displayed. The user then knows that
    credential renewal is required.
    
    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcb97394c1d36ec62de59963f5e08cfff61b9c81
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Sun Jul 28 22:30:57 2013 -0400

    drm/nva3-/disp: fix hda eld writing, needs to be padded
    
    commit 02d69294a174d7cb6a76080b6d16971ca08728d4 upstream.
    
    Commits 0a9e2b959 (drm/nvd0/disp: move HDA codec setup to core) and
    a4feaf4ea (drm/nva3/disp: move hda codec handling to core) moved code
    around but neglected to fill data up to 0x60 as before. This caused
    /proc/asound/cardN/eld#3.0 to show eld_valid as 0. With this patch, that
    file is again populated with the correct data.
    
    See https://bugs.freedesktop.org/show_bug.cgi?id=67051
    
    Reported-and-tested-by: Alex <alupu01@gmail.com>
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdfe8f670850dc576d108424ed47208a422e62d3
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Sun Jul 28 21:00:23 2013 +0100

    drm/nv50-/disp: remove dcb_outp_match call, and related variables
    
    commit 9a7046d55f319b2dde5d2536cc2adb01ebdbe09e upstream.
    
    Unused and irrelavant since the code move of DP training/linkcontrol interrupt
    
    Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b444df2f5791fb1ddf7d6b771ee32e30cc29dad9
Author: Greg Thelen <gthelen@google.com>
Date:   Thu Nov 21 14:32:00 2013 -0800

    ipc,shm: fix shm_file deletion races
    
    commit a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1 upstream.
    
    When IPC_RMID races with other shm operations there's potential for
    use-after-free of the shm object's associated file (shm_file).
    
    Here's the race before this patch:
    
      TASK 1                     TASK 2
      ------                     ------
      shm_rmid()
        ipc_lock_object()
                                 shmctl()
                                 shp = shm_obtain_object_check()
    
        shm_destroy()
          shum_unlock()
          fput(shp->shm_file)
                                 ipc_lock_object()
                                 shmem_lock(shp->shm_file)
                                 <OOPS>
    
    The oops is caused because shm_destroy() calls fput() after dropping the
    ipc_lock.  fput() clears the file's f_inode, f_path.dentry, and
    f_path.mnt, which causes various NULL pointer references in task 2.  I
    reliably see the oops in task 2 if with shmlock, shmu
    
    This patch fixes the races by:
    1) set shm_file=NULL in shm_destroy() while holding ipc_object_lock().
    2) modify at risk operations to check shm_file while holding
       ipc_object_lock().
    
    Example workloads, which each trigger oops...
    
    Workload 1:
      while true; do
        id=$(shmget 1 4096)
        shm_rmid $id &
        shmlock $id &
        wait
      done
    
      The oops stack shows accessing NULL f_inode due to racing fput:
        _raw_spin_lock
        shmem_lock
        SyS_shmctl
    
    Workload 2:
      while true; do
        id=$(shmget 1 4096)
        shmat $id 4096 &
        shm_rmid $id &
        wait
      done
    
      The oops stack is similar to workload 1 due to NULL f_inode:
        touch_atime
        shmem_mmap
        shm_mmap
        mmap_region
        do_mmap_pgoff
        do_shmat
        SyS_shmat
    
    Workload 3:
      while true; do
        id=$(shmget 1 4096)
        shmlock $id
        shm_rmid $id &
        shmunlock $id &
        wait
      done
    
      The oops stack shows second fput tripping on an NULL f_inode.  The
      first fput() completed via from shm_destroy(), but a racing thread did
      a get_file() and queued this fput():
        locks_remove_flock
        __fput
        ____fput
        task_work_run
        do_notify_resume
        int_signal
    
    Fixes: c2c737a0461e ("ipc,shm: shorten critical region for shmat")
    Fixes: 2caacaa82a51 ("ipc,shm: shorten critical region for shmctl")
    Signed-off-by: Greg Thelen <gthelen@google.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Manfred Spraul <manfred@colorfullife.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 c6cac65e0d07f9a4c57b68702db945db6e0321f7
Author: Jesper Nilsson <jesper.nilsson@axis.com>
Date:   Thu Nov 21 14:32:08 2013 -0800

    ipc,shm: correct error return value in shmctl (SHM_UNLOCK)
    
    commit 3a72660b07d86d60457ca32080b1ce8c2b628ee2 upstream.
    
    Commit 2caacaa82a51 ("ipc,shm: shorten critical region for shmctl")
    restructured the ipc shm to shorten critical region, but introduced a
    path where the return value could be -EPERM, even if the operation
    actually was performed.
    
    Before the commit, the err return value was reset by the return value
    from security_shm_shmctl() after the if (!ns_capable(...)) statement.
    
    Now, we still exit the if statement with err set to -EPERM, and in the
    case of SHM_UNLOCK, it is not reset at all, and used as the return value
    from shmctl.
    
    To fix this, we only set err when errors occur, leaving the fallthrough
    case alone.
    
    Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Michel Lespinasse <walken@google.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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef1c63283fc95d0e60904937f5a428cc2c9236bd
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Mon Oct 28 09:54:40 2013 +0100

    can: c_can: Fix RX message handling, handle lost message before EOB
    
    commit 5d0f801a2ccec3b1fdabc3392c8d99ed0413d216 upstream.
    
    If we handle end of block messages with higher priority than a lost message,
    we can run into an endless interrupt loop.
    
    This is reproducable with a am335x processor and "cansequence -r" at 1Mbit.
    As soon as we loose a packet we can't escape from an interrupt loop.
    
    This patch fixes the problem by handling lost packets before EOB packets.
    
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4821fd9dea0feb827b9d0ecda3463227ada05d52
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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8a7dd7122d411662e7ccf9986070fbe2ac2aeb2
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Tue Sep 17 08:33:11 2013 -0400

    crypto: ansi_cprng - Fix off by one error in non-block size request
    
    commit 714b33d15130cbb5ab426456d4e3de842d6c5b8a upstream.
    
    Stephan Mueller reported to me recently a error in random number generation in
    the ansi cprng. If several small requests are made that are less than the
    instances block size, the remainder for loop code doesn't increment
    rand_data_valid in the last iteration, meaning that the last bytes in the
    rand_data buffer gets reused on the subsequent smaller-than-a-block request for
    random data.
    
    The fix is pretty easy, just re-code the for loop to make sure that
    rand_data_valid gets incremented appropriately
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
    CC: Stephan Mueller <stephan.mueller@atsec.com>
    CC: Petr Matousek <pmatouse@redhat.com>
    CC: Herbert Xu <herbert@gondor.apana.org.au>
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e467973ad083f10d5eee5c08429c63f2b5fd671
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Sun Oct 27 22:07:53 2013 +0100

    can: kvaser_usb: fix usb endpoints detection
    
    commit 896e23bd04ea50a146dffd342e2f96180f0812a5 upstream.
    
    Some devices, like the Kvaser Memorator Professional, have several bulk in
    endpoints. Only the first one found must be used by the driver. The same holds
    for the bulk out endpoint. The official Kvaser driver (leaf) was used as
    reference for this patch.
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7471b5f424c444727014ec6a72b6008e62fafef4
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Oct 9 17:01:09 2013 +0200

    USB: mos7840: fix tiocmget error handling
    
    commit a91ccd26e75235d86248d018fe3779732bcafd8d upstream.
    
    Make sure to return errors from tiocmget rather than rely on
    uninitialised stack data.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 217e7268258cf7a23196093dc828a0d0736aeb13
Author: Bob Moore <robert.moore@intel.com>
Date:   Fri Sep 6 14:27:15 2013 +0800

    ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field.
    
    commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.
    
    This change fixes a problem where a Store operation to an ArgX object
    that contained a reference to a field object did not complete the
    automatic dereference and then write to the actual field object.
    Instead, the object type of the field object was inadvertently changed
    to match the type of the source operand. The new behavior will actually
    write to the field object (buffer field or field unit), thus matching
    the correct ACPI-defined behavior.
    
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97020dadef81be7b3f1af758406a97d02c1cfa6b
Author: Bob Moore <robert.moore@intel.com>
Date:   Thu Aug 8 15:29:58 2013 +0800

    ACPICA: Return error if DerefOf resolves to a null package element.
    
    commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.
    
    Disallow the dereference of a reference (via index) to an uninitialized
    package element. Provides compatibility with other ACPI
    implementations. ACPICA BZ 1003.
    
    References: https://bugs.acpica.org/show_bug.cgi?id=431
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0417642d6541b4583cdebbb031f8c020029400e7
Author: Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com>
Date:   Thu Oct 31 14:01:02 2013 +0530

    aacraid: prevent invalid pointer dereference
    
    commit b4789b8e6be3151a955ade74872822f30e8cd914 upstream.
    
    It appears that driver runs into a problem here if fibsize is too small
    because we allocate user_srbcmd with fibsize size only but later we
    access it until user_srbcmd->sg.count to copy it over to srbcmd.
    
    It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this
    structure already includes one sg element and this is not needed for
    commands without data.  So, we would recommend to add the following
    (instead of test for fibsize == 0).
    
    Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com>
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    libertas: potential oops in debugfs
    
    commit a497e47d4aec37aaf8f13509f3ef3d1f6a717d88 upstream.
    
    If we do a zero size allocation then it will oops.  Also we can't be
    sure the user passes us a NUL terminated string so I've added a
    terminator.
    
    This code can only be triggered by root.
    
    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: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82eb7924131196deccf9f09fd29d96960bc48200
Author: Bob Moore <robert.moore@intel.com>
Date:   Thu Aug 8 15:29:32 2013 +0800

    ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.
    
    commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.
    
    Previously, references to these objects were resolved only to the actual
    FieldUnit or BufferField object. The correct behavior is to resolve these
    references to an actual value.
    The problem is that DerefOf did not resolve these objects to actual
    values.  An "Integer" object is simple, return the value.  But a field in
    an operation region will require a read operation.  For a BufferField, the
    appropriate data must be extracted from the parent buffer.
    
    NOTE: It appears that this issues is present in Windows7 but not
    Windows8.
    
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>