commit 02709ef60b70874443d375a91ea98f2e12aba0d7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 13 12:08:24 2013 +0900

    Linux 3.11.8

commit 51dcd49f16772e41318fee7ad5b477661f0c84df
Author: Jon Mason <jon.mason@intel.com>
Date:   Tue Jul 30 15:58:49 2013 -0700

    NTB: Correct debugfs to work with more than 1 NTB Device
    
    commit 1517a3f21a1dd321f16bcf44204bddff9d21abd0 upstream.
    
    Debugfs was setup in NTB to only have a single debugfs directory.  This
    resulted in the leaking of debugfs directories and files when multiple
    NTB devices were present, due to each device stomping on the variables
    containing the previous device's values (thus preventing them from being
    freed on cleanup).  Correct this by creating a secondary directory of
    the PCI BDF for each device present, and nesting the previously existing
    information in those directories.
    
    Signed-off-by: Jon Mason <jon.mason@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5da1ca75f78746e35357679c184d2107d880e9ec
Author: Jon Mason <jon.mason@intel.com>
Date:   Fri May 31 14:05:53 2013 -0700

    NTB: Correct USD/DSD Identification
    
    commit b6750cfe0710a14fd147ba27fddbecae8ba88c77 upstream.
    
    Due to ambiguous documentation, the USD/DSD identification is backward
    when compared to the setting in BIOS.  Correct the bits to match the
    BIOS setting.
    
    Signed-off-by: Jon Mason <jon.mason@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec56e56b6d4ed6edb38358edd26f5b9fb87eb3f5
Author: Jon Mason <jon.mason@intel.com>
Date:   Mon Jul 15 15:26:14 2013 -0700

    NTB: Correct Number of Scratch Pad Registers
    
    commit 87034511519815259e37336f52edf06d114d43b6 upstream.
    
    The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back
    scratch pad registers.  Correct the #define to represent this and update
    the variable names to reflect their usage.
    
    Signed-off-by: Jon Mason <jon.mason@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7803b56d3b0d29a0231af3164dc7d3d9e86ded90
Author: Jon Mason <jon.mason@intel.com>
Date:   Mon Jul 15 13:23:47 2013 -0700

    NTB: Add Error Handling in ntb_device_setup
    
    commit 3b12a0d15bd1559e72ad21d9d807fd2a6706f0ab upstream.
    
    If an error is encountered in ntb_device_setup, it is possible that the
    spci_cmd isn't populated.  Writes to the offset can result in a NULL
    pointer dereference.  This issue is easily encountered by running in
    NTB-RP mode, as it currently is not supported and will generate an
    error.  To get around this issue, return if an error is encountered
    prior to attempting to write to the spci_cmd offset.
    
    Signed-off-by: Jon Mason <jon.mason@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24460c53b7f00ab1ba55e07377a0351175cf395a
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date:   Fri Oct 25 18:15:06 2013 +0800

    seq_file: always update file->f_pos in seq_lseek()
    
    commit 05e16745c0c471bba313961b605b6da3b21a853d upstream.
    
    This issue was first pointed out by Jiaxing Wang several months ago, but no
    further comments:
    https://lkml.org/lkml/2013/6/29/41
    
    As we know pread() does not change f_pos, so after pread(), file->f_pos
    and m->read_pos become different. And seq_lseek() does not update file->f_pos
    if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
    m->read_pos), then a subsequent read may read from a wrong position, the
    following program produces the problem:
    
        char str1[32] = { 0 };
        char str2[32] = { 0 };
        int poffset = 10;
        int count = 20;
    
        /*open any seq file*/
        int fd = open("/proc/modules", O_RDONLY);
    
        pread(fd, str1, count, poffset);
        printf("pread:%s\n", str1);
    
        /*seek to where m->read_pos is*/
        lseek(fd, poffset+count, SEEK_SET);
    
        /*supposed to read from poffset+count, but this read from position 0*/
        read(fd, str2, count);
        printf("read:%s\n", str2);
    
    out put:
    pread:
     ck_netbios_ns 12665
    read:
     nf_conntrack_netbios
    
    /proc/modules:
    nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
    nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000
    
    So we always update file->f_pos to offset in seq_lseek() to fix this issue.
    
    Signed-off-by: Jiaxing Wang <hello.wjx@gmail.com>
    Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Jonghwan Choi <jhbird.choi@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97f61e059bf498022b88fd800ed629018bacfcc2
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Oct 17 19:45:29 2013 +0900

    mutex: Avoid gcc version dependent __builtin_constant_p() usage
    
    commit b0267507dfd0187fb7840a0ec461a510a7f041c5 upstream.
    
    Commit 040a0a37 ("mutex: Add support for wound/wait style locks")
    used "!__builtin_constant_p(p == NULL)" but gcc 3.x cannot
    handle such expression correctly, leading to boot failure when
    built with CONFIG_DEBUG_MUTEXES=y.
    
    Fix it by explicitly passing a bool which tells whether p != NULL
    or not.
    
    [ PeterZ: This is a sad patch, but provided it actually generates
              similar code I suppose its the best we can do bar whole
    	  sale deprecating gcc-3. ]
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Cc: peterz@infradead.org
    Cc: imirkin@alum.mit.edu
    Cc: daniel.vetter@ffwll.ch
    Cc: robdclark@gmail.com
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/201310171945.AGB17114.FSQVtHOJFOOFML@I-love.SAKURA.ne.jp
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51528f7f9d6795fa67accdc5543a51949c416a42
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Oct 29 12:04:08 2013 +0100

    drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
    
    commit 1fbc0d789d12fec313c91912fc11733fdfbab863 upstream.
    
    Originally I've thought that this is leftover hw state dirt from the
    BIOS. But after way too much helpless flailing around on my part I've
    noticed that the actual bug is when we change the state of an already
    active pipe.
    
    For example when we change the fdi lines from 2 to 3 without switching
    off outputs in-between we'll never see the crucial on->off transition
    in the ->modeset_global_resources hook the current logic relies on.
    
    Patch version 2 got this right by instead also checking whether the
    pipe is indeed active. But that in turn broke things when pipes have
    been turned off through dpms since the bifurcate enabling is done in
    the ->crtc_mode_set callback.
    
    To address this issues discussed with Ville in the patch review move
    the setting of the bifurcate bit into the ->crtc_enable hook. That way
    we won't wreak havoc with this state when userspace puts all other
    outputs into dpms off state. This also moves us forward with our
    overall goal to unify the modeset and dpms on paths (which we need to
    have to allow runtime pm in the dpms off state).
    
    Unfortunately this requires us to move the bifurcate helpers around a
    bit.
    
    Also update the commit message, I've misanalyzed the bug rather badly.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
    Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d727a6888ac39dee06bbefcda50596a7c85105aa
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 4eef610aa86d861efcb43ce4a8f741c55e806bf3
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Oct 21 10:52:06 2013 +0300

    drm/i915: Add support for pipe_bpp readout
    
    commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399 upstream.
    
    On CTG+ read out the pipe bpp setting from hardware and fill it into
    pipe config. Also check it appropriately.
    
    v2: Don't do the pipe_bpp extraction inside the PCH only code block on
        ILK+.
        Avoid the PIPECONF read as we already have read it for the
        PIPECONF_EANBLE check.
    
    Note: This is already in drm-intel-next-queued as
    commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
    Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Date:   Fri Sep 6 23:29:00 2013 +0300
    
        drm/i915: Add support for pipe_bpp readout
    
    but is needed for the following bugfix.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9741538fbf9191a46b80333e003a49ea34d789d3
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Sep 24 14:24:05 2013 +0300

    drm/i915: Add HSW CRT output readout support
    
    commit 7195a50b5c7e00cc3312934fd022c3006b533d12 upstream.
    
    Call intel_ddi_get_config() to get the pipe_bpp settings from
    DDI.
    
    The sync polarity settings from DDI are irrelevant for CRT
    output, so override them with data from the ADPA register.
    
    Note: This is already merged in drm-intel-next-queued as
    
    commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d
    Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Date:   Tue Sep 24 14:24:05 2013 +0300
    
        drm/i915: Add HSW CRT output readout support
    
    but is required for the following edp bpp bugfix.
    
    v2: Extract intel_crt_get_flags()
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
    Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25f1734b8fc6531dce3b8c9de5423bee71b76035
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Oct 16 11:36:30 2013 -0400

    drm/radeon: make missing smc ucode non-fatal (r7xx-SI)
    
    commit d83671126dc8e7c0b56c9970ea5ffd08c3b0c645 upstream.
    
    Prevent driver load problems if the smc is missing.
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=63011
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1417cc5548ba834a8ecef56f86ae682670b12490
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Oct 10 16:45:27 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs780
    
    commit c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.
    
    Some rs780 asics seem to be affected as well.
    
    See:
    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72
    
    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=60791
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm: Pad drm_mode_get_connector to 64-bit boundary
    
    commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
    
    Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
    the 4 bytes beyond the end of its structure with a 32-bit userspace
    running on a 64-bit kernel. This is due to the padding gcc inserts as
    the drm_mode_get_connector struct includes a u64 and its size is not a
    natural multiple of u64s.
    
    64-bit kernel:
    
    sizeof(drm_mode_get_connector)=80, alignof=8
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4
    
    32-bit userspace:
    
    sizeof(drm_mode_get_connector)=76, alignof=4
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4
    
    Fortuituously we can insert explicit padding to the tail of our
    structures without breaking ABI.
    
    Reported-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8528076a9922966b93b7b12e104cd3fdcd8fee3f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 16 11:22:44 2013 +0100

    drm: Prevent overwriting from userspace underallocating core ioctl structs
    
    commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
    
    Apply the protections from
    
    commit 1b2f1489633888d4a06028315dc19d65768a1c05
    Author: Dave Airlie <airlied@redhat.com>
    Date:   Sat Aug 14 20:20:34 2010 +1000
    
        drm: block userspace under allocating buffer and having drivers overwrite it (v2)
    
    to the core ioctl structs as well, for we found one instance where there
    is a 32-/64-bit size mismatch and were guilty of writing beyond the end
    of the user's buffer.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef4ea0912a5dd2b67353f83acd09d651650cba8f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jul 21 16:00:03 2013 +0100

    drm/i915: Retry DP aux_ch communications with a different clock after failure
    
    commit bc86625a4ff7574d4d4dba79723457711eb784e0 upstream.
    
    The w/a db makes the recommendation to both use a non-default value for
    the initial clock and then to retry with an alternative clock for
    Haswell with the Lakeport PCH.
    
    "On LPT:H, use a divider value of 63 decimal (03Fh). If there is a
    failure, retry at least three times with 63, then retry at least three
    times with 72 decimal (048h)."
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 141d9920e281a4597379b7f43c9c2b9fa340b22a
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Thu Jul 11 18:44:57 2013 -0300

    drm/i915: split aux_clock_divider logic in a separated function for reuse.
    
    commit b84a1cf8950ed075c4ab2630514d4caaae504176 upstream.
    
    Prep patch for reuse aux_clock_divider with EDP_PSR_AUX_CTL setup.
    
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb0bb972b5b6798a94fbe08330a7ac83284b301a
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Wed Oct 9 01:42:51 2013 -0700

    drm/vmwgfx: Don't kill clients on VT switch
    
    commit c4249855ac5b2a383704d31e040d3831d6a25c6f upstream.
    
    DRI clients that tried to grab the TTM lock when the master (X server) was
    switched away during a VT switch were sent the SIGTERM signal by the
    kernel. Fix this so that they are only sent that signal when the master has
    exited.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 598b53ebd0836be3b0d9ffdb100ca83baae506d7
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Wed Oct 9 01:42:50 2013 -0700

    drm/vmwgfx: Don't put resources with invalid id's on lru list
    
    commit 26682480c202e7360cbcdc3bc9e962bf749c6b8d upstream.
    
    The evict code may try to swap them out causing a BUG in the destroy
    function.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c082ab303b4d639e464d9b439b98f983cd6d9078
Author: Chen LinX <linx.z.chen@intel.com>
Date:   Wed Oct 30 13:56:18 2013 -0700

    mm/pagewalk.c: fix walk_page_range() access of wrong PTEs
    
    commit 3017f079efd6af199b0852b5c425364513db460e upstream.
    
    When walk_page_range walk a memory map's page tables, it'll skip
    VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it
    maybe larger than 'end'.  In next loop, 'addr' will be larger than
    'next'.  Then in /proc/XXXX/pagemap file reading procedure, the 'addr'
    will growing forever in pagemap_pte_range, pte_to_pagemap_entry will
    access the wrong pte.
    
      BUG: Bad page map in process procrank  pte:8437526f pmd:785de067
      addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping:  (null) index:9108d
      CPU: 1 PID: 4974 Comm: procrank Tainted: G    B   W  O 3.10.1+ #1
      Call Trace:
        dump_stack+0x16/0x18
        print_bad_pte+0x114/0x1b0
        vm_normal_page+0x56/0x60
        pagemap_pte_range+0x17a/0x1d0
        walk_page_range+0x19e/0x2c0
        pagemap_read+0x16e/0x200
        vfs_read+0x84/0x150
        SyS_read+0x4a/0x80
        syscall_call+0x7/0xb
    
    Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
    Signed-off-by: Chen LinX <linx.z.chen@intel.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d24630054984909554a35c21e2cb06816bc26e5
Author: Cyrill Gorcunov <gorcunov@gmail.com>
Date:   Wed Oct 16 13:46:53 2013 -0700

    mm: /proc/pid/pagemap: inspect _PAGE_SOFT_DIRTY only on present pages
    
    commit e9cdd6e771580e6ff872e5c64e8b766972c7d1bc upstream.
    
    If a page we are inspecting is in swap we may occasionally report it as
    having soft dirty bit (even if it is clean).  The pte_soft_dirty helper
    should be called on present pte only.
    
    Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4064c039975b16ae0f61b40128bb50e369e0cbd4
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:47 2013 +0100

    mm: Account for a THP NUMA hinting update as one PTE update
    
    commit 0255d491848032f6c601b6410c3b8ebded3a37b1 upstream.
    
    A THP PMD update is accounted for as 512 pages updated in vmstat.  This is
    large difference when estimating the cost of automatic NUMA balancing and
    can be misleading when comparing results that had collapsed versus split
    THP. This patch addresses the accounting issue.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-10-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e7b837d6d0ee70d557fe32d03544c681ef8c807
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:46 2013 +0100

    mm: Close races between THP migration and PMD numa clearing
    
    commit 3f926ab945b60a5824369d21add7710622a2eac0 upstream.
    
    THP migration uses the page lock to guard against parallel allocations
    but there are cases like this still open
    
      Task A					Task B
      ---------------------				---------------------
      do_huge_pmd_numa_page				do_huge_pmd_numa_page
      lock_page
      mpol_misplaced == -1
      unlock_page
      goto clear_pmdnuma
    						lock_page
    						mpol_misplaced == 2
    						migrate_misplaced_transhuge
      pmd = pmd_mknonnuma
      set_pmd_at
    
    During hours of testing, one crashed with weird errors and while I have
    no direct evidence, I suspect something like the race above happened.
    This patch extends the page lock to being held until the pmd_numa is
    cleared to prevent migration starting in parallel while the pmd_numa is
    being cleared. It also flushes the old pmd entry and orders pagetable
    insertion before rmap insertion.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-9-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5af02fe9c4721c3c227e9b4af8450aa4b11cc0e
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:45 2013 +0100

    mm: numa: Sanitize task_numa_fault() callsites
    
    commit c61109e34f60f6e85bb43c5a1cd51c0e3db40847 upstream.
    
    There are three callers of task_numa_fault():
    
     - do_huge_pmd_numa_page():
         Accounts against the current node, not the node where the
         page resides, unless we migrated, in which case it accounts
         against the node we migrated to.
    
     - do_numa_page():
         Accounts against the current node, not the node where the
         page resides, unless we migrated, in which case it accounts
         against the node we migrated to.
    
     - do_pmd_numa_page():
         Accounts not at all when the page isn't migrated, otherwise
         accounts against the node we migrated towards.
    
    This seems wrong to me; all three sites should have the same
    sementaics, furthermore we should accounts against where the page
    really is, we already know where the task is.
    
    So modify all three sites to always account; we did after all receive
    the fault; and always account to where the page is after migration,
    regardless of success.
    
    They all still differ on when they clear the PTE/PMD; ideally that
    would get sorted too.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-8-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93a21ff24ff631ae0cc43785dfef9a19ed11f0c6
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:44 2013 +0100

    mm: Prevent parallel splits during THP migration
    
    commit 587fe586f44a48f9691001ba6c45b86c8e4ba21f upstream.
    
    THP migrations are serialised by the page lock but on its own that does
    not prevent THP splits. If the page is split during THP migration then
    the pmd_same checks will prevent page table corruption but the unlock page
    and other fix-ups potentially will cause corruption. This patch takes the
    anon_vma lock to prevent parallel splits during migration.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-7-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3753635515193a32d7c93cb1ba56943245a31eb3
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:43 2013 +0100

    mm: Wait for THP migrations to complete during NUMA hinting faults
    
    commit 42836f5f8baa33085f547098b74aa98991ee9216 upstream.
    
    The locking for migrating THP is unusual. While normal page migration
    prevents parallel accesses using a migration PTE, THP migration relies on
    a combination of the page_table_lock, the page lock and the existance of
    the NUMA hinting PTE to guarantee safety but there is a bug in the scheme.
    
    If a THP page is currently being migrated and another thread traps a
    fault on the same page it checks if the page is misplaced. If it is not,
    then pmd_numa is cleared. The problem is that it checks if the page is
    misplaced without holding the page lock meaning that the racing thread
    can be migrating the THP when the second thread clears the NUMA bit
    and faults a stale page.
    
    This patch checks if the page is potentially being migrated and stalls
    using the lock_page if it is potentially being migrated before checking
    if the page is misplaced or not.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-6-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9fac9b5433e504c9c4f8f4e73f9b1e70551fb2
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Oct 7 11:28:42 2013 +0100

    mm: numa: Do not account for a hinting fault if we raced
    
    commit 1dd49bfa3465756b3ce72214b58a33e4afb67aa3 upstream.
    
    If another task handled a hinting fault in parallel then do not double
    account for it.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1381141781-10992-5-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e181a455cf06c53e0c008190bfe2b4773ed0beb
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Sep 13 21:45:51 2013 +0200

    clk: nomadik: set all timers to use 2.4 MHz TIMCLK
    
    commit b9b5ab11ea221a9f2d5af41da639e0898675c34c upstream.
    
    This fixes a regression for the Nomadik on the main system
    timers.
    
    The Nomadik seemed a bit slow and its heartbeat wasn't looking
    healthy. And it was not strange, because it has been connected
    to the 32768 Hz clock at boot, while being told by the clock driver
    that it was 2.4MHz. Actually connect the TIMCLK to 2.4MHz by
    default as this is what we want for nice scheduling, clocksource
    and clock event.
    
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61bcdfc3d95ad7f6d8991652ace93f830c7d2f44
Author: Jonathan Austin <jonathan.austin@arm.com>
Date:   Tue Jul 23 16:42:18 2013 +0100

    clk: fixup argument order when setting VCO parameters
    
    commit 2f9f64bc5aa31836810cd25301aa4772ad73ebab upstream.
    
    The order of arguments in the call to vco_set() for the ICST clocks appears to
    have been switched in error, which results in the VCO not being initialised
    correctly. This in turn stops the integrated LCD on things like Integrator/CP
    from working correctly.
    
    This patch fixes the order and restores the expected functionality.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2af344097ce82d1772d709229adcf02390c3f1b5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:11:06 2013 +0300

    aacraid: missing capable() check in compat ioctl
    
    commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.
    
    In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
    added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
    check as well.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1a8b8606455ac9bdd329a59fcd04ecc686cf464
Author: Ming Lei <ming.lei@canonical.com>
Date:   Thu Oct 31 16:34:17 2013 -0700

    lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
    
    commit 3d77b50c5874b7e923be946ba793644f82336b75 upstream.
    
    Commit b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
    functions") introduces two sg buffer copy helpers, and calls
    flush_kernel_dcache_page() on pages in SG list after these pages are
    written to.
    
    Unfortunately, the commit may introduce a potential bug:
    
     - Before sending some SCSI commands, kmalloc() buffer may be passed to
       block layper, so flush_kernel_dcache_page() can see a slab page
       finally
    
     - According to cachetlb.txt, flush_kernel_dcache_page() is only called
       on "a user page", which surely can't be a slab page.
    
     - ARCH's implementation of flush_kernel_dcache_page() may use page
       mapping information to do optimization so page_mapping() will see the
       slab page, then VM_BUG_ON() is triggered.
    
    Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
    and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
    before calling flush_kernel_dcache_page().
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Simon Baatz <gmbnomis@gmail.com>
    Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    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 2f571b30258eb05d90a06e8473cb616c71e822d8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Oct 29 10:21:34 2013 -0700

    Fix a few incorrectly checked [io_]remap_pfn_range() calls
    
    commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1 upstream.
    
    Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
    really should use the vm_iomap_memory() helper.  This trivially converts
    two of them to the helper, and comments about why the third one really
    needs to continue to use remap_pfn_range(), and adds the missing size
    check.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f4df5cd4308788d9fadc53dbafc4a82f1664066
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Aug 7 13:02:53 2013 +0200

    uio: provide vm access to UIO_MEM_PHYS maps
    
    commit 7294151d0592e0ff48c61fca9fd7c93d613134da upstream.
    
    This makes it possible to let gdb access mappings of the process that is
    being debugged.
    
    uio_mmap_logical was moved and uio_vm_ops renamed to group related code
    and differentiate to new stuff.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2dbe5ab0ee1992fb7134c561518183b511fb81a
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Aug 7 13:02:52 2013 +0200

    mm: make generic_access_phys available for modules
    
    commit 5a73633ef01cd8772defa6a3c34a588376a1df4c upstream.
    
    In the next commit this function will be used in the uio subsystem
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c67180d8b89a31e98e71a6d8eb4b01fb2b3a57fd
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Tue Oct 15 02:22:43 2013 +0400

    xtensa: don't use alternate signal stack on threads
    
    commit cba9a90053e3b7973eff4f1946f33032e98eeed5 upstream.
    
    According to create_thread(3): "The new thread does not inherit the creating
    thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack
    corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
    processes sharing VM with their parent. Don't use the (nonexistent) alternate
    signal stack in this case. This has been broken since commit 29c4dfd9 ([XTENSA]
    Remove non-rt signal handling).
    
    Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.
    
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Chris Zankel <chris@zankel.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdc5b2a53590400883693d6946ba5fa11e4c918e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:06:04 2013 +0300

    uml: check length in exitcode_proc_write()
    
    commit 201f99f170df14ba52ea4c52847779042b7a623b upstream.
    
    We don't cap the size of buffer from the user so we could write past the
    end of the array here.  Only root can write to this file.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f7c41c84814e5deb18e800227dfaa9ce47ff072
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:00:15 2013 +0300

    staging: wlags49_h2: buffer overflow setting station name
    
    commit b5e2f339865fb443107e5b10603e53bbc92dc054 upstream.
    
    We need to check the length parameter before doing the memcpy().  I've
    actually changed it to strlcpy() as well so that it's NUL terminated.
    
    You need CAP_NET_ADMIN to trigger these so it's not the end of the
    world.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21e2e64525f28a9a7c3c29848992a6dfeb877191
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:01:43 2013 +0300

    Staging: sb105x: info leak in mp_get_count()
    
    commit a8b33654b1e3b0c74d4a1fed041c9aae50b3c427 upstream.
    
    The icount.reserved[] array isn't initialized so it leaks stack
    information to userspace.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe6e2eab80efdc706aee9d83c70961cc4ae9c17f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:01:11 2013 +0300

    Staging: bcm: info leak in ioctl
    
    commit 8d1e72250c847fa96498ec029891de4dc638a5ba upstream.
    
    The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
    information to user space.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0622771fb23e520ce667ef7d9ed2670ec2223897
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:07:47 2013 +0300

    staging: ozwpan: prevent overflow in oz_cdev_write()
    
    commit c2c65cd2e14ada6de44cb527e7f1990bede24e15 upstream.
    
    We need to check "count" so we don't overflow the ei->data buffer.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6de317283eb18f5f766305fb7770ebc9760994e8
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 28 14:21:49 2013 +0100

    ASoC: dapm: Fix source list debugfs outputs
    
    commit ff18620c2157671a8ee21ebb8e6a3520ea209b1f upstream.
    
    ... due to a copy & paste error.
    
    Spotted by coverity CID 710923.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6eb542209451e4a81501d3c118399013bd66426
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 08:35:02 2013 +0100

    ASoC: wm_hubs: Add missing break in hp_supply_event()
    
    commit 268ff14525edba31da29a12a9dd693cdd6a7872e upstream.
    
    Spotted by coverity CID 115170.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c8f27d4c51b57795ad8a2f206ac81ffba819e9a
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Oct 31 15:01:37 2013 +0000

    ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM
    
    commit a4461f41b94cb52e0141af717dcf4ef6558c8e2e upstream.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000008
    pgd = d5300000
    [00000008] *pgd=0d265831, *pte=00000000, *ppte=00000000
    Internal error: Oops: 17 [#1] PREEMPT ARM
    CPU: 0 PID: 2295 Comm: vlc Not tainted 3.11.0+ #755
    task: dee74800 ti: e213c000 task.ti: e213c000
    PC is at snd_pcm_info+0xc8/0xd8
    LR is at 0x30232065
    pc : [<c031b52c>]    lr : [<30232065>]    psr: a0070013
    sp : e213dea8  ip : d81cb0d0  fp : c05f7678
    r10: c05f7770  r9 : fffffdfd  r8 : 00000000
    r7 : d8a968a8  r6 : d8a96800  r5 : d8a96200  r4 : d81cb000
    r3 : 00000000  r2 : d81cb000  r1 : 00000001  r0 : d8a96200
    Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 10c5387d  Table: 15300019  DAC: 00000015
    Process vlc (pid: 2295, stack limit = 0xe213c248)
    [<c031b52c>] (snd_pcm_info) from [<c031b570>] (snd_pcm_info_user+0x34/0x9c)
    [<c031b570>] (snd_pcm_info_user) from [<c03164a4>] (snd_pcm_control_ioctl+0x274/0x280)
    [<c03164a4>] (snd_pcm_control_ioctl) from [<c0311458>] (snd_ctl_ioctl+0xc0/0x55c)
    [<c0311458>] (snd_ctl_ioctl) from [<c00eca84>] (do_vfs_ioctl+0x80/0x31c)
    [<c00eca84>] (do_vfs_ioctl) from [<c00ecd5c>] (SyS_ioctl+0x3c/0x60)
    [<c00ecd5c>] (SyS_ioctl) from [<c000e500>] (ret_fast_syscall+0x0/0x48)
    Code: e1a00005 e59530dc e3a01001 e1a02004 (e5933008)
    ---[ end trace cb3d9bdb8dfefb3c ]---
    
    This is provoked when the ASoC front end is open along with its backend,
    (which causes the backend to have a runtime assigned to it) and then the
    SNDRV_CTL_IOCTL_PCM_INFO is requested for the (visible) backend device.
    
    Resolve this by ensuring that ASoC internal backend devices are not
    visible to userspace, just as the commentry for snd_pcm_new_internal()
    says it should be.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Acked-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51ad39f8592d7d208ae8fd321c708aedf4ce6020
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 12:29:40 2013 +0100

    ALSA: hda - Add a fixup for ASUS N76VZ
    
    commit 6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.
    
    ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
    speaker.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846529
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1471eb15b7b25c5da001d65e42c4d39ce334f6c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 24 01:20:24 2013 +0200

    ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4
    
    commit e6bbe666673ab044a3d39ddb74e4d9a401cf1d6f upstream.
    
    When a machine goes to S3/S4 after power-save is enabled, the runtime
    PM refcount might be incorrectly decreased because the power-down
    triggered soon after resume assumes that the controller was already
    powered up, and issues the pm_notify down.
    
    This patch fixes the incorrect pm_notify call simply by checking the
    current value properly.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77ee1271696b85cbeaf617e6630769ad28b728fd
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Oct 25 23:43:10 2013 +0200

    ALSA: hda - Add missing initial vmaster hook at build_controls callback
    
    commit b63eae0a6c84839275a4638a7baa391be965cd0e upstream.
    
    The generic parser has a support of vmaster hook, but this is
    initialized only in the init callback with the check of the presence
    of the corresponding kctl.  However, since kctl is NULL at the very
    first init callback that is called before build_controls callback, the
    vmaster hook sync is skipped there.  Eventually this leads to the
    uninitialized state depending on the hook implementation.
    
    This patch adds a simple workaround, just calling the sync function
    explicitly at build_controls callback.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d3a5278be634f01bf1a304ebd719848e154e1ff
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Sat Nov 2 17:47:49 2013 +0530

    ARC: Incorrect mm reference used in vmalloc fault handler
    
    commit 9c41f4eeb9d51f3ece20428d35a3ea32cf3b5622 upstream.
    
    A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current
    task's "active_mm".  ARC vmalloc fault handler however was using mm.
    
    A vmalloc fault for non user task context (actually pre-userland, from
    init thread's open for /dev/console) caused the handler to deref NULL mm
    (for mm->pgd)
    
    The reasons it worked so far is amazing:
    
    1. By default (!SMP), vmalloc fault handler uses a cached value of PGD.
       In SMP that MMU register is repurposed hence need for mm pointer deref.
    
    2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in
       pre-userland code path - it was introduced with commit 20bafb3d23d108bc
       "n_tty: Move buffers into n_tty_data"
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Cc: Gilad Ben-Yossef <gilad@benyossef.com>
    Cc: Noam Camus <noamc@ezchip.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c891251cabbc6e95b6de2ab1ece4873d918ae643
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Sat Nov 2 09:11:33 2013 +1030

    scripts/kallsyms: filter symbols not in kernel address space
    
    commit f6537f2f0eba4eba3354e48dbe3047db6d8b6254 upstream.
    
    This patch uses CONFIG_PAGE_OFFSET to filter symbols which
    are not in kernel address space because these symbols are
    generally for generating code purpose and can't be run at
    kernel mode, so we needn't keep them in /proc/kallsyms.
    
    For example, on ARM there are some symbols which may be
    linked in relocatable code section, then perf can't parse
    symbols any more from /proc/kallsyms, this patch fixes the
    problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fefdfec714df1e1a2c82936f979fcd815a631b0
Author: Helge Deller <deller@gmx.de>
Date:   Sat Oct 26 23:19:25 2013 +0200

    parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM
    
    commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.
    
    Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
    not able to bring up other CPUs than the monarch CPU and instead crashed the
    kernel.  The reason was unclear, esp. since it involved various machines (e.g.
    J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
    when less than 4GB were installed, or if a 32bit Linux kernel was booted.
    
    In the end, the fix for those SMP problems is trivial:
    During the early phase of the initialization of the CPUs, including the monarch
    CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
    It's documented that this firmware function may clobber various registers, and
    one one of those possibly clobbered registers is %cr30 which holds the task
    thread info pointer.
    
    Now, if %cr30 would always have been clobbered, then this bug would have been
    detected much earlier. But lots of testing finally showed, that - at least for
    %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
    turned zero after the firmware call.
    
    So, after finding the root cause, the explanation for the various crashes
    became clear:
    - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
      problem.
    - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
      thread info pointer was below 4GB.
    - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
      the upper 32bit were zero anyay.
    - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
      info pointer was located above the 4GB boundary.
    
    Finally, the patch to fix this problem is trivial by saving the %cr30 register
    before the firmware call and restoring it afterwards.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 728ccd1f9a6e8ec19e001d8b4d1e2930c9034068
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Sep 24 21:50:23 2013 +0200

    clockevents: Sanitize ticks to nsec conversion
    
    commit 97b9410643475d6557d2517c2aff9fd2221141a9 upstream.
    
    Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use
    clockevents_config_and_register() where possible" caused a regression
    for some of the converted subarchs.
    
    The reason is, that the clockevents core code converts the minimal
    hardware tick delta to a nanosecond value for core internal
    usage. This conversion is affected by integer math rounding loss, so
    the backwards conversion to hardware ticks will likely result in a
    value which is less than the configured hardware limitation. The
    affected subarchs used their own workaround (SIGH!) which got lost in
    the conversion.
    
    The solution for the issue at hand is simple: adding evt->mult - 1 to
    the shifted value before the integer divison in the core conversion
    function takes care of it. But this only works for the case where for
    the scaled math mult/shift pair "mult <= 1 << shift" is true. For the
    case where "mult > 1 << shift" we can apply the rounding add only for
    the minimum delta value to make sure that the backward conversion is
    not less than the given hardware limit. For the upper bound we need to
    omit the rounding add, because the backwards conversion is always
    larger than the original latch value. That would violate the upper
    bound of the hardware device.
    
    Though looking closer at the details of that function reveals another
    bogosity: The upper bounds check is broken as well. Checking for a
    resulting "clc" value greater than KTIME_MAX after the conversion is
    pointless. The conversion does:
    
          u64 clc = (latch << evt->shift) / evt->mult;
    
    So there is no sanity check for (latch << evt->shift) exceeding the
    64bit boundary. The latch argument is "unsigned long", so on a 64bit
    arch the handed in argument could easily lead to an unnoticed shift
    overflow. With the above rounding fix applied the calculation before
    the divison is:
    
           u64 clc = (latch << evt->shift) + evt->mult - 1;
    
    So we need to make sure, that neither the shift nor the rounding add
    is overflowing the u64 boundary.
    
    [ukl: move assignment to rnd after eventually changing mult, fix build
     issue and correct comment with the right math]
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Cc: Marc Kleine-Budde <mkl@pengutronix.de>
    Cc: nicolas.ferre@atmel.com
    Cc: Marc Pignat <marc.pignat@hevs.ch>
    Cc: john.stultz@linaro.org
    Cc: kernel@pengutronix.de
    Cc: Ronald Wahl <ronald.wahl@raritan.com>
    Cc: LAK <linux-arm-kernel@lists.infradead.org>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Link: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47b4a5c772de4df3c908f7d9d70ededf3a98290
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Oct 25 10:44:15 2013 -0700

    vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter
    
    commit 60a01f558af9c48b0bb31f303c479e32721add3f upstream.
    
    This patch addresses a long-standing bug where the get_user_pages_fast()
    write parameter used for setting the underlying page table entry permission
    bits was incorrectly set to write=1 for data_direction=DMA_TO_DEVICE, and
    passed into get_user_pages_fast() via vhost_scsi_map_iov_to_sgl().
    
    However, this parameter is intended to signal WRITEs to pinned userspace
    PTEs for the virtio-scsi DMA_FROM_DEVICE -> READ payload case, and *not*
    for the virtio-scsi DMA_TO_DEVICE -> WRITE payload case.
    
    This bug would manifest itself as random process segmentation faults on
    KVM host after repeated vhost starts + stops and/or with lots of vhost
    endpoints + LUNs.
    
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Asias He <asias@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    target/pscsi: fix return value check
    
    commit 58932e96e438cd78f75e765d7b87ef39d3533d15 upstream.
    
    In case of error, the function scsi_host_lookup() returns NULL
    pointer not ERR_PTR(). The IS_ERR() test in the return value check
    should be replaced with NULL test.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 246d77a83ed063b021484961e3e2a67096231640
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Oct 8 09:47:22 2013 -0700

    target: Fix assignment of LUN in tracepoints
    
    commit 2053a1db41193c2b5e1f47a91aaba0fd63ba7102 upstream.
    
    The unpacked_lun field in the SCSI target tracepoints should be
    initialized with cmd->orig_fe_lun rather than cmd->se_lun->unpacked_lun
    for two reasons:
    
     - most importantly, if we are in the cmd_complete tracepoint
       returning a check condition due to no LUN found, cmd->se_lun will
       be NULL and we'll crash trying to dereference it.
    
     - also, in any case, cmd->se_lun->unpacked_lun is an internal index
       into the target's internal set of LUNs; cmd->orig_fe_lun is much
       more useful and interesting, since it's the value the initiator
       actually sent.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 790c6e06934c132f5bdbce4fbf791236272f9763
Author: Lukasz Dorau <lukasz.dorau@intel.com>
Date:   Thu Oct 24 12:55:17 2013 +1100

    md: Fix skipping recovery for read-only arrays.
    
    commit 61e4947c99c4494336254ec540c50186d186150b upstream.
    
    Since:
            commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86
            md: Allow devices to be re-added to a read-only array.
    
    spares are activated on a read-only array. In case of raid1 and raid10
    personalities it causes that not-in-sync devices are marked in-sync
    without checking if recovery has been finished.
    
    If a read-only array is degraded and one of its devices is not in-sync
    (because the array has been only partially recovered) recovery will be skipped.
    
    This patch adds checking if recovery has been finished before marking a device
    in-sync for raid1 and raid10 personalities. In case of raid5 personality
    such condition is already present (at raid5.c:6029).
    
    Bug was introduced in 3.10 and causes data corruption.
    
    Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b00915de0908f436868671f1febeb03943f7a34
Author: Bian Yu <bianyu@kedacom.com>
Date:   Sat Oct 12 01:10:03 2013 -0400

    md: avoid deadlock when md_set_badblocks.
    
    commit 905b0297a9533d7a6ee00a01a990456636877dd6 upstream.
    
    When operate harddisk and hit errors, md_set_badblocks is called after
    scsi_restart_operations which already disabled the irq. but md_set_badblocks
    will call write_sequnlock_irq and enable irq. so softirq can preempt the
    current thread and that may cause a deadlock. I think this situation should
    use write_sequnlock_irqsave/irqrestore instead.
    
    I met the situation and the call trace is below:
    [  638.919974] BUG: spinlock recursion on CPU#0, scsi_eh_13/1010
    [  638.921923]  lock: 0xffff8800d4d51fc8, .magic: dead4ead, .owner: scsi_eh_13/1010, .owner_cpu: 0
    [  638.923890] CPU: 0 PID: 1010 Comm: scsi_eh_13 Not tainted 3.12.0-rc5+ #37
    [  638.925844] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS 4.6.5 03/05/2013
    [  638.927816]  ffff880037ad4640 ffff880118c03d50 ffffffff8172ff85 0000000000000007
    [  638.929829]  ffff8800d4d51fc8 ffff880118c03d70 ffffffff81730030 ffff8800d4d51fc8
    [  638.931848]  ffffffff81a72eb0 ffff880118c03d90 ffffffff81730056 ffff8800d4d51fc8
    [  638.933884] Call Trace:
    [  638.935867]  <IRQ>  [<ffffffff8172ff85>] dump_stack+0x55/0x76
    [  638.937878]  [<ffffffff81730030>] spin_dump+0x8a/0x8f
    [  638.939861]  [<ffffffff81730056>] spin_bug+0x21/0x26
    [  638.941836]  [<ffffffff81336de4>] do_raw_spin_lock+0xa4/0xc0
    [  638.943801]  [<ffffffff8173f036>] _raw_spin_lock+0x66/0x80
    [  638.945747]  [<ffffffff814a73ed>] ? scsi_device_unbusy+0x9d/0xd0
    [  638.947672]  [<ffffffff8173fb1b>] ? _raw_spin_unlock+0x2b/0x50
    [  638.949595]  [<ffffffff814a73ed>] scsi_device_unbusy+0x9d/0xd0
    [  638.951504]  [<ffffffff8149ec47>] scsi_finish_command+0x37/0xe0
    [  638.953388]  [<ffffffff814a75e8>] scsi_softirq_done+0xa8/0x140
    [  638.955248]  [<ffffffff8130e32b>] blk_done_softirq+0x7b/0x90
    [  638.957116]  [<ffffffff8104fddd>] __do_softirq+0xfd/0x330
    [  638.958987]  [<ffffffff810b964f>] ? __lock_release+0x6f/0x100
    [  638.960861]  [<ffffffff8174a5cc>] call_softirq+0x1c/0x30
    [  638.962724]  [<ffffffff81004c7d>] do_softirq+0x8d/0xc0
    [  638.964565]  [<ffffffff8105024e>] irq_exit+0x10e/0x150
    [  638.966390]  [<ffffffff8174ad4a>] smp_apic_timer_interrupt+0x4a/0x60
    [  638.968223]  [<ffffffff817499af>] apic_timer_interrupt+0x6f/0x80
    [  638.970079]  <EOI>  [<ffffffff810b964f>] ? __lock_release+0x6f/0x100
    [  638.971899]  [<ffffffff8173fa6a>] ? _raw_spin_unlock_irq+0x3a/0x50
    [  638.973691]  [<ffffffff8173fa60>] ? _raw_spin_unlock_irq+0x30/0x50
    [  638.975475]  [<ffffffff81562393>] md_set_badblocks+0x1f3/0x4a0
    [  638.977243]  [<ffffffff81566e07>] rdev_set_badblocks+0x27/0x80
    [  638.978988]  [<ffffffffa00d97bb>] raid5_end_read_request+0x36b/0x4e0 [raid456]
    [  638.980723]  [<ffffffff811b5a1d>] bio_endio+0x1d/0x40
    [  638.982463]  [<ffffffff81304ff3>] req_bio_endio.isra.65+0x83/0xa0
    [  638.984214]  [<ffffffff81306b9f>] blk_update_request+0x7f/0x350
    [  638.985967]  [<ffffffff81306ea1>] blk_update_bidi_request+0x31/0x90
    [  638.987710]  [<ffffffff813085e0>] __blk_end_bidi_request+0x20/0x50
    [  638.989439]  [<ffffffff8130862f>] __blk_end_request_all+0x1f/0x30
    [  638.991149]  [<ffffffff81308746>] blk_peek_request+0x106/0x250
    [  638.992861]  [<ffffffff814a62a9>] ? scsi_kill_request.isra.32+0xe9/0x130
    [  638.994561]  [<ffffffff814a633a>] scsi_request_fn+0x4a/0x3d0
    [  638.996251]  [<ffffffff813040a7>] __blk_run_queue+0x37/0x50
    [  638.997900]  [<ffffffff813045af>] blk_run_queue+0x2f/0x50
    [  638.999553]  [<ffffffff814a5750>] scsi_run_queue+0xe0/0x1c0
    [  639.001185]  [<ffffffff814a7721>] scsi_run_host_queues+0x21/0x40
    [  639.002798]  [<ffffffff814a2e87>] scsi_restart_operations+0x177/0x200
    [  639.004391]  [<ffffffff814a4fe9>] scsi_error_handler+0xc9/0xe0
    [  639.005996]  [<ffffffff814a4f20>] ? scsi_unjam_host+0xd0/0xd0
    [  639.007600]  [<ffffffff81072f6b>] kthread+0xdb/0xe0
    [  639.009205]  [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170
    [  639.010821]  [<ffffffff81748cac>] ret_from_fork+0x7c/0xb0
    [  639.012437]  [<ffffffff81072e90>] ? flush_kthread_worker+0x170/0x170
    
    This bug was introduce in commit  2e8ac30312973dd20e68073653
    (the first time rdev_set_badblock was call from interrupt context),
    so this patch is appropriate for 3.5 and subsequent kernels.
    
    Signed-off-by: Bian Yu <bianyu@kedacom.com>
    Reviewed-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83da8ac7ee52d56e9bf5626502cca6e8e169580c
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Oct 29 23:43:08 2013 +0100

    Revert "select: use freezable blocking call"
    
    commit 59612d187912750f416fbffe0c00bc0811c54ab5 upstream.
    
    This reverts commit 9745cdb36da8 (select: use freezable blocking call)
    that triggers problems during resume from suspend to RAM on Paul Bolle's
    32-bit x86 machines.  Paul says:
    
      Ever since I tried running (release candidates of) v3.11 on the two
      working i686s I still have lying around I ran into issues on resuming
      from suspend. Reverting 9745cdb36da8 (select: use freezable blocking
      call) resolves those issues.
    
      Resuming from suspend on i686 on (release candidates of) v3.11 and
      later triggers issues like:
    
      traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000]
    
      and
    
      traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000]
    
      Once I hit the systemd error I can only get out of the mess that the
      system is at that point by power cycling it.
    
    Since we are reverting another freezer-related change causing similar
    problems to happen, this one should be reverted as well.
    
    References: https://lkml.org/lkml/2013/10/29/583
    Reported-by: Paul Bolle <pebolle@tiscali.nl>
    Fixes: 9745cdb36da8 (select: use freezable blocking call)
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7668bd83b5e7fd1519b1fd92226a948299692e6b
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Oct 29 13:12:56 2013 +0100

    Revert "epoll: use freezable blocking call"
    
    commit c511851de162e8ec03d62e7d7feecbdf590d881d upstream.
    
    This reverts commit 1c441e921201 (epoll: use freezable blocking call)
    which is reported to cause user space memory corruption to happen
    after suspend to RAM.
    
    Since it appears to be extremely difficult to root cause this
    problem, it is best to revert the offending commit and try to address
    the original issue in a better way later.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=61781
    Reported-by: Natrio <natrio@list.ru>
    Reported-by: Jeff Pohlmeyer <yetanothergeek@gmail.com>
    Bisected-by: Leo Wolf <jclw@ymail.com>
    Fixes: 1c441e921201 (epoll: use freezable blocking call)
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5804987902e8ab21459acd70217f889e06447d5
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Sep 23 04:08:13 2013 +0200

    Revert "rt2x00pci: Use PCI MSIs whenever possible"
    
    commit dfb6b7c109a7f98d324a759599d1b4616f02c79f upstream.
    
    This reverts commit 9483f40d8d01918b399b4e24d0c1111db0afffeb.
    
    Some devices stop to connect with above commit, see:
    https://bugzilla.kernel.org/show_bug.cgi?id=61621
    
    Since there is no clear benefit of having MSI enabled, just revert
    change to fix the problem.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Jakub Kicinski <kubakici@wp.pl>
    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 ababf744ce845f93bf9810753cec861b0e6c97f8
Author: Gwendal Grignou <gwendal@google.com>
Date:   Fri Aug 7 16:17:49 2009 -0700

    libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures
    
    commit f13e220161e738c2710b9904dcb3cf8bb0bcce61 upstream.
    
    libata EH decrements scmd->retries when the command failed for reasons
    unrelated to the command itself so that, for example, commands aborted
    due to suspend / resume cycle don't get penalized; however,
    decrementing scmd->retries isn't enough for ATA passthrough commands.
    
    Without this fix, ATA passthrough commands are not resend to the
    drive, and no error is signalled to the caller because:
    
    - allowed retry count is 1
    - ata_eh_qc_complete fill the sense data, so result is valid
    - sense data is filled with untouched ATA registers.
    
    Signed-off-by: Gwendal Grignou <gwendal@google.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8aabed06e0f51f4a71540350bb62c79d2913c54b
Author: Shaohua Li <shli@kernel.org>
Date:   Sat Oct 19 14:51:42 2013 +0800

    raid5: avoid finding "discard" stripe
    
    commit d47648fcf0611812286f68131b40251c6fa54f5e upstream.
    
    SCSI discard will damage discard stripe bio setting, eg, some fields are
    changed. If the stripe is reused very soon, we have wrong bios setting. We
    remove discard stripe from hash list, so next time the strip will be fully
    initialized.
    
    Suitable for backport to 3.7+.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2a097d602f04c485b73deee3476a502edae3ac9
Author: Shaohua Li <shli@kernel.org>
Date:   Sat Oct 19 14:50:28 2013 +0800

    raid5: set bio bi_vcnt 0 for discard request
    
    commit 37c61ff31e9b5e3fcf3cc6579f5c68f6ad40c4b1 upstream.
    
    SCSI layer will add new payload for discard request. If two bios are merged
    to one, the second bio has bi_vcnt 1 which is set in raid5. This will confuse
    SCSI and cause oops.
    
    Suitable for backport to 3.7+
    
    Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ca6a948fb97c27ae9f352c254063f7fe342d30c
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Oct 24 14:08:07 2013 +0000

    eCryptfs: fix 32 bit corruption issue
    
    commit 43b7c6c6a4e3916edd186ceb61be0c67d1e0969e upstream.
    
    Shifting page->index on 32 bit systems was overflowing, causing
    data corruption of > 4GB files. Fix this by casting it first.
    
    https://launchpad.net/bugs/1243636
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reported-by: Lars Duesing <lars.duesing@camelotsweb.de>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff2d90ef8a5f51c8aceb61156fd276da36eb158f
Author: Geyslan G. Bem <geyslan@gmail.com>
Date:   Fri Oct 11 16:49:16 2013 -0300

    ecryptfs: Fix memory leakage in keystore.c
    
    commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream.
    
    In 'decrypt_pki_encrypted_session_key' function:
    
    Initializes 'payload' pointer and releases it on exit.
    
    Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 836a6eec8e00243f10b40b066673e572d690adf7
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Thu Oct 10 13:22:36 2013 +0800

    SCSI: sd: call blk_pm_runtime_init before add_disk
    
    commit 10c580e4239df5c3344ca00322eca86ab2de880b upstream.
    
    Sujit has found a race condition that would make q->nr_pending
    unbalanced, it occurs as Sujit explained:
    
    "
    sd_probe_async() ->
    	add_disk() ->
    		disk_add_event() ->
    			schedule(disk_events_workfn)
    	sd_revalidate_disk()
    	blk_pm_runtime_init()
    return;
    
    Let's say the disk_events_workfn() calls sd_check_events() which tries
    to send test_unit_ready() and because of sd_revalidate_disk() trying to
    send another commands the test_unit_ready() might be re-queued as the
    tagged command queuing is disabled.
    
    So the race condition is -
    
    Thread 1 			  |		Thread 2
    sd_revalidate_disk()		  |	sd_check_events()
    ...nr_pending = 0 as q->dev = NULL|	scsi_queue_insert()
    blk_runtime_pm_init()		  | 	blk_pm_requeue_request() ->
    				  |	nr_pending = -1 since
    				  |	q->dev != NULL
    "
    
    The problem is, the test_unit_ready request doesn't get counted the
    first time it is queued, so the later decrement of q->nr_pending in
    blk_pm_requeue_request makes it unbalanced.
    
    Fix this by calling blk_pm_runtime_init before add_disk so that all
    requests initiated there will all be counted.
    
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Reported-and-tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e353d5ce7cc2c6636bde123869e43b3b007708f2
Author: Khalid Aziz <khalid.aziz@oracle.com>
Date:   Wed Sep 25 11:45:11 2013 -0600

    SCSI: BusLogic: Fix an oops when intializing multimaster adapter
    
    commit 6541932ea2f7de0b0c5203decf666b143ad5fa33 upstream.
    
    This fixes an oops caused by buslogic driver when initializing a BusLogic
    MultiMaster adapter. Initialization code used scope of a variable
    incorrectly which created a NULL pointer. Oops message is below:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000c
    IP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583
    *pde = 00000000
    Oops: 002 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.1.puz1 #1
    Hardware name:    /Canterwood, BIOS 6.00 PG 05/16/2003
    task: f7050000 ti: f7054000 task.ti: f7054000
    EIP: 0060:[<c150c137>] EFLAGS: 00010246 CPU:1
    EIP is at blogic_init_mm_probeinfo.isra.17+0x20a/0x583
    EAX: 00000013 EBX: 00000000 ECX: 00000000 EDX: f8001000
    ESI: f71cb800 EDI: f7388000 EBP: 00007800 ESP: f7055c84
     DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    CR0: 8005003b CR2: 0000000c CR3: 0154f000 CR4: 000007d0
    Stack:
     0000001c 00000000 c11a59f6 f7055c98 00008130 ffffffff ffffffff 00000000
     00000003 00000000 00000000 00000000 00000013 f8001000 00000001 000003d0
     00000000 00000000 00000000 c14e3f84 f78803c8 00000000 f738c000 000000e9
    Call Trace:
     [<c11a59f6>] ? pci_get_subsys+0x33/0x38
     [<c150c4fb>] ? blogic_init_probeinfo_list+0x4b/0x19e
     [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623
     [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623
     [<c10fb99e>] ? sysfs_link_sibling+0x61/0x8d
     [<c10b0519>] ? kmem_cache_alloc+0x8b/0xb5
     [<c150cce5>] ? blogic_init+0xa1/0x10e8
     [<c10fc0a8>] ? sysfs_add_one+0x10/0x9d
     [<c10fc18a>] ? sysfs_addrm_finish+0x12/0x85
     [<c10fca37>] ? sysfs_do_create_link_sd+0x9d/0x1b4
     [<c117c272>] ? blk_register_queue+0x69/0xb3
     [<c10fcb68>] ? sysfs_create_link+0x1a/0x2c
     [<c1181a07>] ? add_disk+0x1a1/0x3c7
     [<c138737b>] ? klist_next+0x60/0xc3
     [<c122cc3a>] ? scsi_dh_detach+0x68/0x68
     [<c1213e36>] ? bus_for_each_dev+0x51/0x61
     [<c1000356>] ? do_one_initcall+0x22/0x12c
     [<c10f3688>] ? __proc_create+0x8c/0xba
     [<c150cc44>] ? blogic_setup+0x5f6/0x5f6
     [<c14e94aa>] ? repair_env_string+0xf/0x4d
     [<c14e949b>] ? do_early_param+0x71/0x71
     [<c103efaa>] ? parse_args+0x21f/0x33d
     [<c14e9a54>] ? kernel_init_freeable+0xdf/0x17d
     [<c14e949b>] ? do_early_param+0x71/0x71
     [<c1388b64>] ? kernel_init+0x8/0xc0
     [<c1392222>] ? ret_from_kernel_thread+0x6/0x28
     [<c1392227>] ? ret_from_kernel_thread+0x1b/0x28
     [<c1388b5c>] ? rest_init+0x6c/0x6c
    Code: 89 44 24 10 0f b6 44 24 3d 89 44 24 0c c7 44 24 08 00 00 00 00 c7 44 24 04 38 62 46 c1 c7 04 24 02 00 00 00 e8 78 13 d2 ff 31 db <89> 6b 0c b0 20 89 ea ee
     c7 44 24 08 04 00 00 00 8d 44 24 4c 89
    EIP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583 SS:ESP 0068:f7055c84
    CR2: 000000000000000c
    ---[ end trace 17f45f5196d40487 ]---
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
    
    Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
    Reported-by: Pierre Uszynski <pierre@rahul.net>
    Tested-by: Pierre Uszynski <pierre@rahul.net>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96424f593af6d547c677b91d3570827895db51bf
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 4 10:52:36 2013 +0200

    can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX
    
    commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.
    
    In patch
    
        0d1862e can: flexcan: fix flexcan_chip_start() on imx6
    
    the loop in flexcan_chip_start() that iterates over all mailboxes after the
    soft reset of the CAN core was removed. This loop put all mailboxes (even the
    ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
    this aborts any pending TX messages.
    
    After a cold boot there is random garbage in the mailboxes, which leads to
    spontaneous transmit of CAN frames during first activation. Further if the
    interface was disabled with a pending message (usually due to an error
    condition on the CAN bus), this message is retransmitted after enabling the
    interface again.
    
    This patch fixes the regression by:
    1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
    FIFO, 8 is used by TX.
    2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
    mailbox is aborted.
    
    Cc: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7443e576411e4c16b63f68d979a605013b8f8c8
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Oct 3 23:51:55 2013 +0200

    can: flexcan: fix mx28 detection by rearanging OF match table
    
    commit e358784297992b012e8071764d996191dd2b1a54 upstream.
    
    The current implemetation of of_match_device() relies that the of_device_id
    table in the driver is sorted from most specific to least specific compatible.
    
    Without this patch the mx28 is detected as the less specific p1010. This leads
    to a p1010 specific workaround is activated on the mx28, which is not needed.
    
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf089b665ab4c8c27daed6259adaa90793970a3a
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 9 12:19:19 2013 +0200

    can: at91-can: fix device to driver data mapping for platform devices
    
    commit 5abbeea553c8260ed4e2ac4aae962aff800b6c6d upstream.
    
    In commit:
    
        3078cde7 can: at91_can: add dt support
    
    device tree support was added to the at91_can driver. In this commit the
    mapping of device to driver data was mixed up. This results in the sam9x5
    parameters being used for the sam9263 and the workaround for the broken mailbox
    0 on the sam9263 not being activated.
    
    This patch fixes the broken platform_device_id table.
    
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2bab673619581372fae453569d247063708b706
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Fri Sep 6 21:49:56 2013 -0500

    jfs: fix error path in ialloc
    
    commit 8660998608cfa1077e560034db81885af8e1e885 upstream.
    
    If insert_inode_locked() fails, we shouldn't be calling
    unlock_new_inode().
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Tested-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f00f0f238a5e9624bd651f939a34b009cdb9dc9d
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Sep 24 19:34:26 2013 +0300

    iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series
    
    commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream.
    
    Add some new PCI IDs to the table for 6000, 6005 and 6235 series.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb59afeec59a06583359f685290ebb1eeff7a42e
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sun Sep 15 14:39:02 2013 +0300

    iwlwifi: mvm: call ieee80211_scan_completed when needed
    
    commit 5a3e9f7f8c8768b5f7df81100c684e4cd00a6eb5 upstream.
    
    When RFKill cuts short a scan, mac80211 cancels the scan.
    This is done by sending a host command to the firmware, but
    this command was dropped because of RFKill. Flag this
    command as "SEND_IN_RFKILL" to make sure it is sent to the
    firmware. The firmware will send SCAN_COMPLETE_NOTIFICATION
    which will trigger a call to ieee80211_scan_completed.
    
    If the scan cannot be aborted, it is because the firmware
    already finished the scan but we hadn't notified mac80211
    at the time mac80211 decided to cancel the scan. By the time
    we see the scan could not be aborted, mac80211 has been
    notified already.
    
    This patch fixes situations in which we didn't notify
    mac80211 upon completion of the scan that was cut short
    by RFkill.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35a9611020cc8d42995c77e30db9e2e48ec831f0
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date:   Tue Oct 8 10:18:20 2013 -0500

    rtlwifi: rtl8192cu: Fix error in pointer arithmetic
    
    commit 9473ca6e920a3b9ca902753ce52833657f9221cc upstream.
    
    An error in calculating the offset in an skb causes the driver to read
    essential device info from the wrong locations. The main effect is that
    automatic gain calculations are nonsense.
    
    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecaa9a5393c6efea168c0092058a44e67c6ffa23
Author: Amitkumar Karwar <akarwar@marvell.com>
Date:   Fri Sep 27 10:55:38 2013 -0700

    mwifiex: fix SDIO interrupt lost issue
    
    commit 453b0c3f6910672f79da354077af728d92f95c5b upstream.
    
    601216e "mwifiex: process RX packets in SDIO IRQ thread directly"
    introduced a command timeout issue which can be reproduced easily on
    an AM33xx platform using a test application written by Daniel Mack:
    
    https://gist.github.com/zonque/6579314
    
    mwifiex_main_process() is called from both the SDIO handler and
    the workqueue. In case an interrupt occurs right after the
    int_status check, but before updating the mwifiex_processing flag,
    this interrupt gets lost, resulting in a command timeout and
    consequently a card reset.
    
    Let main_proc_lock protect both int_status and mwifiex_processing
    flag. This fixes the interrupt lost issue.
    
    Reported-by: Sven Neumann <s.neumann@raumfeld.com>
    Reported-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
    Tested-by: Daniel Mack <zonque@gmail.com>
    Reviewed-by: Dylan Reid <dgreid@chromium.org>
    Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: Paul Stewart <pstew@chromium.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ace6195f05329e8c1e18b4a45c2f605ac922042
Author: Bruno Randolf <br1@einfach.org>
Date:   Thu Sep 26 16:55:28 2013 +0100

    cfg80211: fix warning when using WEXT for IBSS
    
    commit f478f33a93f9353dcd1fe55445343d76b1c3f84a upstream.
    
    Fix kernel warning when using WEXT for configuring ad-hoc mode,
    e.g.  "iwconfig wlan0 essid test channel 1"
    
    WARNING: at net/wireless/chan.c:373 cfg80211_chandef_usable+0x50/0x21c [cfg80211]()
    
    The warning is caused by an uninitialized variable center_freq1.
    
    Signed-off-by: Bruno Randolf <br1@einfach.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1252286e425da7485af9bb0506c029ac61de30df
Author: Luciano Coelho <luciano.coelho@intel.com>
Date:   Thu Aug 29 13:26:57 2013 +0300

    cfg80211: use the correct macro to check for active monitor support
    
    commit 180032973ee97daddf5c9d733e5b425b108f8679 upstream.
    
    Use MONITOR_FLAG_ACTIVE, which is a flag mask, instead of
    NL80211_MNTR_FLAG_ACTIVE, which is a flag index, when checking if the
    hardware supports active monitoring.
    
    Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eca970de7c31574810e80ed780b8a661fc703213
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Oct 5 14:09:30 2013 +0200

    ath9k: fix tx queue scheduling after channel changes
    
    commit ec30326ea773900da210c495e14cfeb532550ba2 upstream.
    
    Otherwise, if queues are full during a scan, tx scheduling does not
    resume after switching back to the home channel.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94579b022349f6e2c991a94154d09af81591f2c4
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Oct 11 15:47:06 2013 +0200

    mac80211: fix crash if bitrate calculation goes wrong
    
    commit d86aa4f8ca58898ec6a94c0635da20b948171ed7 upstream.
    
    If a frame's timestamp is calculated, and the bitrate
    calculation goes wrong and returns zero, the system
    will attempt to divide by zero and crash. Catch this
    case and print the rate information that the driver
    reported when this happens.
    
    Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0be5e3842206b504deb190e8c325bf775a2b4c48
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Sep 29 21:39:34 2013 +0200

    mac80211: update sta->last_rx on acked tx frames
    
    commit 0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.
    
    When clients are idle for too long, hostapd sends nullfunc frames for
    probing. When those are acked by the client, the idle time needs to be
    updated.
    
    To make this work (and to avoid unnecessary probing), update sta->last_rx
    whenever an ACK was received for a tx packet. Only do this if the flag
    IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3426c0268bf7971cdce1996981a72da1b0948f19
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Sep 29 21:39:33 2013 +0200

    mac80211: use sta_info_get_bss() for nl80211 tx and client probing
    
    commit 03bb7f42765ce596604f03d179f3137d7df05bba upstream.
    
    This allows calls for clients in AP_VLANs (e.g. for 4-addr) to succeed
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    mac80211: drop spoofed packets in ad-hoc mode
    
    commit 6329b8d917adc077caa60c2447385554130853a3 upstream.
    
    If an Ad-Hoc node receives packets with the Cell ID or its own MAC
    address as source address, it hits a WARN_ON in sta_info_insert_check()
    With many packets, this can massively spam the logs. One way that this
    can easily happen is through having Cisco APs in the area with rouge AP
    detection and countermeasures enabled.
    Such Cisco APs will regularly send fake beacons, disassoc and deauth
    packets that trigger these warnings.
    
    To fix this issue, drop such spoofed packets early in the rx path.
    
    Reported-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a18be8d6d721a7197395ad1fe63376c315a09ef
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Sep 16 11:12:07 2013 +0300

    mac80211: correctly close cancelled scans
    
    commit a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.
    
    __ieee80211_scan_completed is called from a worker. This
    means that the following flow is possible.
    
     * driver calls ieee80211_scan_completed
     * mac80211 cancels the scan (that is already complete)
     * __ieee80211_scan_completed runs
    
    When scan_work will finally run, it will see that the scan
    hasn't been aborted and might even trigger another scan on
    another band. This leads to a situation where cfg80211's
    scan is not done and no further scan can be issued.
    
    Fix this by setting a new flag when a HW scan is being
    cancelled so that no other scan will be triggered.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e6787c87c004aa26866b26e3eb44cf0b478ce0d
Author: Anjana V Kumar <anjanavk12@gmail.com>
Date:   Sat Oct 12 10:59:17 2013 +0800

    cgroup: fix to break the while loop in cgroup_attach_task() correctly
    
    commit ea84753c98a7ac6b74e530b64c444a912b3835ca upstream.
    
    Both Anjana and Eunki reported a stall in the while_each_thread loop
    in cgroup_attach_task().
    
    It's because, when we attach a single thread to a cgroup, if the cgroup
    is exiting or is already in that cgroup, we won't break the loop.
    
    If the task is already in the cgroup, the bug can lead to another thread
    being attached to the cgroup unexpectedly:
    
      # echo 5207 > tasks
      # cat tasks
      5207
      # echo 5207 > tasks
      # cat tasks
      5207
      5215
    
    What's worse, if the task to be attached isn't the leader of the thread
    group, we might never exit the loop, hence cpu stall. Thanks for Oleg's
    analysis.
    
    This bug was introduced by commit 081aa458c38ba576bdd4265fc807fa95b48b9e79
    ("cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()")
    
    [ lizf: - fixed the first continue, pointed out by Oleg,
            - rewrote changelog. ]
    
    Reported-by: Eunki Kim <eunki_kim@samsung.com>
    Reported-by: Anjana V Kumar <anjanavk12@gmail.com>
    Signed-off-by: Anjana V Kumar <anjanavk12@gmail.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6eb6d51d889536075ed37f3549888cd5912ae29
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Fri Oct 18 16:26:22 2013 +0200

    HID: wiimote: add LEGO-wiimote VID
    
    commit 86b84167d4e67372376a57ea9955c5d53dae232f upstream.
    
    The LEGO-wiimote uses a different VID than the Nintendo ID. The device is
    technically the same so add the ID.
    
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dec45604d70422f6b1b93abf2bcf98c9532b296
Author: Kent Overstreet <kmo@daterainc.com>
Date:   Tue Oct 22 15:35:50 2013 -0700

    bcache: Fixed incorrect order of arguments to bio_alloc_bioset()
    
    commit d4eddd42f592a0cf06818fae694a3d271f842e4d upstream.
    
    Signed-off-by: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1b9c53bba4b87365354cec96fa3ed76a6cae6d9
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date:   Tue Oct 15 11:06:14 2013 -0700

    cpufreq / intel_pstate: Fix max_perf_pct on resume
    
    commit 52e0a509e5d6f902ec26bc2a8bb02b137dc453be upstream.
    
    If the system is suspended while max_perf_pct is less than 100 percent
    or no_turbo set policy->{min,max} will be set incorrectly with scaled
    values which turn the scaled values into hard limits.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=61241
    Reported-by: Patrick Bartels <petzicus@googlemail.com>
    Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4349fe191c5f4fc824debccfbc8a54d012038c96
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Mon Oct 14 19:36:47 2013 +0100

    cpufreq: s3c64xx: Rename index to driver_data
    
    commit 0e8244322b7fc45fd11a1c45f70b6bacddf4986f upstream.
    
    The index field of cpufreq_frequency_table has been renamed to
    driver_data by commit 5070158 (cpufreq: rename index as driver_data
    in cpufreq_frequency_table).
    
    This patch updates the s3c64xx driver to match.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 593e3eae86d95414bb7c6902676bc9f38013ced6
Author: Russ Anderson <rja@sgi.com>
Date:   Mon Oct 14 11:17:34 2013 -0500

    x86: Update UV3 hub revision ID
    
    commit dd3c9c4b603c664fedc12facf180db0f1794aafe upstream.
    
    The UV3 hub revision ID is different than expected.  The first
    revision was supposed to start at 1 but instead will start at 0.
    
    Signed-off-by: Russ Anderson <rja@sgi.com>
    Link: http://lkml.kernel.org/r/20131014161733.GA6274@sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 055950b91a1132641b62f017fe52f7d72e113322
Author: Jan Klos <honza.klos@gmail.com>
Date:   Sun Oct 6 21:08:20 2013 +0200

    cifs: Fix inability to write files >2GB to SMB2/3 shares
    
    commit 2f6c9479633780ba4a3484bba7eba5a721a5cf20 upstream.
    
    When connecting to SMB2/3 shares, maximum file size is set to non-LFS maximum in superblock. This is due to cap_large_files bit being different for SMB1 and SMB2/3 (where it is just an internal flag that is not negotiated and the SMB1 one corresponds to multichannel capability, so maybe LFS works correctly if server sends 0x08 flag) while capabilities are checked always for the SMB1 bit in cifs_read_super().
    
    The patch fixes this by checking for the correct bit according to the protocol version.
    
    Signed-off-by: Jan Klos <honza.klos@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3d8eec617f5889f7a49c7efe2d8d7d21096d9e3
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Aug 5 13:36:00 2013 -0700

    xhci: Don't enable/disable RWE on bus suspend/resume.
    
    commit f217c980ca980e3a645b7485ea5eae9a747f4945 upstream.
    
    The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable
    remote wakeup for devices in the lower power link state L1.  It has
    nothing to do with the device suspend remote wakeup from L2.  The RWE
    bit is designed to be set once (when USB 2.0 LPM is enabled for the
    port) and cleared only when USB 2.0 LPM is disabled for the port.
    
    The xHCI bus suspend method was setting the RWE bit erroneously, and the
    bus resume method was clearing it.  The xHCI 1.0 specification with
    errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware
    Controlled LPM":
    
    "While Hardware USB2 LPM is enabled, software shall not modify the
    HIRDBESL or RWE fields of the USB2 PORTPMSC register..."
    
    If we have previously enabled USB 2.0 LPM for a device, that means when
    the USB 2.0 bus is resumed, we violate the xHCI specification by
    clearing RWE.  It also means that after a bus resume, the host would
    think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM
    enabled, which is not what we want.
    
    This patch should be backported to kernels as old as 3.2, that
    contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set
    USB2 hardware LPM".  That was the first kernel that supported USB 2.0
    Link PM.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: serial: ftdi_sio: add id for Z3X Box device
    
    commit e1466ad5b1aeda303f9282463d55798d2eda218c upstream.
    
    Custom VID/PID for Z3X Box device, popular tool for cellphone flashing.
    
    Signed-off-by: Alexey E. Kramarenko <alexeyk13@yandex.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8763fe5320d35c791358e837cbbcc9a4b723d5e3
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Oct 16 12:26:07 2013 +0200

    USB: quirks: add touchscreen that is dazzeled by remote wakeup
    
    commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream.
    
    The device descriptors are messed up after remote wakeup
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7baca932367b91222e3b1485da85d90a5f144dd
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Oct 14 16:22:40 2013 +0200

    USB: quirks.c: add one device that cannot deal with suspension
    
    commit 4294bca7b423d1a5aa24307e3d112a04075e3763 upstream.
    
    The device is not responsive when resumed, unless it is reset.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 334e9ac1d9bdb3cd02ddc74945d5c4293550615e
Author: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Date:   Fri Oct 11 03:48:21 2013 +0000

    USB: support new huawei devices in option.c
    
    commit d544db293a44a2a3b09feab7dbd59668b692de71 upstream.
    
    Add new supporting declarations to option.c, to support Huawei new
    devices with new bInterfaceSubClass value.
    
    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ee7ef780ea3605dd317c6702b50d4a818e64a63
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Oct 14 15:24:55 2013 +0200

    usb-storage: add quirk for mandatory READ_CAPACITY_16
    
    commit 32c37fc30c52508711ea6a108cfd5855b8a07176 upstream.
    
    Some USB drive enclosures do not correctly report an
    overflow condition if they hold a drive with a capacity
    over 2TB and are confronted with a READ_CAPACITY_10.
    They answer with their capacity modulo 2TB.
    The generic layer cannot cope with that. It must be told
    to use READ_CAPACITY_16 from the beginning.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a368a29579b50aa3d78d8b2d9737dd5e32f55a43
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Oct 11 10:38:13 2013 +0200

    usb: musb: start musb on the udc side, too
    
    commit 001dd84a92a25f8f2bad7d26df8bdb0362302c07 upstream.
    
    I have am335x-evm with one port running in OTG mode. Since commit
    fe4cb09 ("usb: musb: gadget: remove hcd initialization") the loaded
    gadget does non pop up on the host. All I see is
    |usb 4-5: new high-speed USB device number 52 using ehci-pci
    |usb 4-5: device descriptor read/64, error -110
    
    Since a later commit 2cc65fe ("usb: musb: add musb_host_setup() and
    musb_host_cleanup()) the gadget shows up on the host again but only
    in OTG mode (because we have the host init code running). It does not
    work in device only mode.
    If running in OTG mode and the gadget is removed and added back (rmmod
    followed by modprobe of a gadget) then the same error is pops up on the
    host side.
    
    This patch ensures that the gadget side also executes musb_start() which
    puts the chip in "connect accept" mode. With this change the device
    works in OTG & device mode and the gadget can be added & removed
    multiple times.
    A device (if musb is in OTG mode acting as a host) is only recognized if
    it is attached during module load (musb_hdrc module). After the device
    unplugged and plugged again the host does not recognize it. We get a
    buch of errors if musb running in OTG mode, attached to a host and no
    gadget is loaded. Bah.
    This is one step forward. Host & device only mode should work. I will
    look at OTG later. I looked at this before commit fe4cb09 and OTG wasn't
    working there perfectly so I am not sure that it is a regression :)
    
    Cc: Daniel Mack <zonque@gmail.com>
    Cc: Peter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>