commit 5a427ce18a14d6b85972c62196a8f10c3624d74a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 16 20:52:24 2015 -0700

    Linux 3.10.87

commit 022d35a6db3423a7354f4d3467871eb389c04ddd
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue Aug 4 14:36:58 2015 -0700

    mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
    
    commit ecf5fc6e9654cd7a268c782a523f072b2f1959f9 upstream.
    
    Nikolay has reported a hang when a memcg reclaim got stuck with the
    following backtrace:
    
    PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
      #0 __schedule at ffffffff815ab152
      #1 schedule at ffffffff815ab76e
      #2 schedule_timeout at ffffffff815ae5e5
      #3 io_schedule_timeout at ffffffff815aad6a
      #4 bit_wait_io at ffffffff815abfc6
      #5 __wait_on_bit at ffffffff815abda5
      #6 wait_on_page_bit at ffffffff8111fd4f
      #7 shrink_page_list at ffffffff81135445
      #8 shrink_inactive_list at ffffffff81135845
      #9 shrink_lruvec at ffffffff81135ead
     #10 shrink_zone at ffffffff811360c3
     #11 shrink_zones at ffffffff81136eff
     #12 do_try_to_free_pages at ffffffff8113712f
     #13 try_to_free_mem_cgroup_pages at ffffffff811372be
     #14 try_charge at ffffffff81189423
     #15 mem_cgroup_try_charge at ffffffff8118c6f5
     #16 __add_to_page_cache_locked at ffffffff8112137d
     #17 add_to_page_cache_lru at ffffffff81121618
     #18 pagecache_get_page at ffffffff8112170b
     #19 grow_dev_page at ffffffff811c8297
     #20 __getblk_slow at ffffffff811c91d6
     #21 __getblk_gfp at ffffffff811c92c1
     #22 ext4_ext_grow_indepth at ffffffff8124565c
     #23 ext4_ext_create_new_leaf at ffffffff81246ca8
     #24 ext4_ext_insert_extent at ffffffff81246f09
     #25 ext4_ext_map_blocks at ffffffff8124a848
     #26 ext4_map_blocks at ffffffff8121a5b7
     #27 mpage_map_one_extent at ffffffff8121b1fa
     #28 mpage_map_and_submit_extent at ffffffff8121f07b
     #29 ext4_writepages at ffffffff8121f6d5
     #30 do_writepages at ffffffff8112c490
     #31 __filemap_fdatawrite_range at ffffffff81120199
     #32 filemap_flush at ffffffff8112041c
     #33 ext4_alloc_da_blocks at ffffffff81219da1
     #34 ext4_rename at ffffffff81229b91
     #35 ext4_rename2 at ffffffff81229e32
     #36 vfs_rename at ffffffff811a08a5
     #37 SYSC_renameat2 at ffffffff811a3ffc
     #38 sys_renameat2 at ffffffff811a408e
     #39 sys_rename at ffffffff8119e51e
     #40 system_call_fastpath at ffffffff815afa89
    
    Dave Chinner has properly pointed out that this is a deadlock in the
    reclaim code because ext4 doesn't submit pages which are marked by
    PG_writeback right away.
    
    The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
    with too many dirty pages") and it was applied only when may_enter_fs
    was specified.  The code has been changed by c3b94f44fcb0 ("memcg:
    further prevent OOM with too many dirty pages") which has removed the
    __GFP_FS restriction with a reasoning that we do not get into the fs
    code.  But this is not sufficient apparently because the fs doesn't
    necessarily submit pages marked PG_writeback for IO right away.
    
    ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
    submit the bio.  Instead it tries to map more pages into the bio and
    mpage_map_one_extent might trigger memcg charge which might end up
    waiting on a page which is marked PG_writeback but hasn't been submitted
    yet so we would end up waiting for something that never finishes.
    
    Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
    before we go to wait on the writeback.  The page fault path, which is
    the only path that triggers memcg oom killer since 3.12, shouldn't
    require GFP_NOFS and so we shouldn't reintroduce the premature OOM
    killer issue which was originally addressed by the heuristic.
    
    As per David Chinner the xfs is doing similar thing since 2.6.15 already
    so ext4 is not the only affected filesystem.  Moreover he notes:
    
    : For example: IO completion might require unwritten extent conversion
    : which executes filesystem transactions and GFP_NOFS allocations. The
    : writeback flag on the pages can not be cleared until unwritten
    : extent conversion completes. Hence memory reclaim cannot wait on
    : page writeback to complete in GFP_NOFS context because it is not
    : safe to do so, memcg reclaim or otherwise.
    
    [tytso@mit.edu: corrected the control flow]
    Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
    Reported-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc0a524cd874cb33146b641c4c8152a22b7da070
Author: NeilBrown <neilb@suse.com>
Date:   Fri Aug 14 17:04:21 2015 +1000

    md/bitmap: return an error when bitmap superblock is corrupt.
    
    commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
        Use separate bitmaps for each nodes in the cluster
    
    bitmap_read_sb() validates the bitmap superblock that it reads in.
    If it finds an inconsistency like a bad magic number or out-of-range
    version number, it prints an error and returns, but it incorrectly
    returns zero, so the array is still assembled with the (invalid) bitmap.
    
    This means it could try to use a bitmap with a new version number which
    it therefore does not understand.
    
    This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
    So the patch is suitable for any -stable kernel in that range.
    
    Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Reported-by: GuoQing Jiang <gqjiang@suse.com>

commit d7a681b77df62857104797f0ebfb47eb6fdc37c6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Sat May 30 14:31:24 2015 +0200

    kvm: x86: fix kvm_apic_has_events to check for NULL pointer
    
    commit ce40cd3fc7fa40a6119e5fe6c0f2bc0eb4541009 upstream.
    
    Malicious (or egregiously buggy) userspace can trigger it, but it
    should never happen in normal operation.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Wang Kai <morgan.wang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6bb935312e2c20c95af0789ec84af4a6bcd5596
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:26 2015 -0700

    signal: fix information leak in copy_siginfo_from_user32
    
    commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 upstream.
    
    This function can leak kernel stack data when the user siginfo_t has a
    positive si_code value.  The top 16 bits of si_code descibe which fields
    in the siginfo_t union are active, but they are treated inconsistently
    between copy_siginfo_from_user32, copy_siginfo_to_user32 and
    copy_siginfo_to_user.
    
    copy_siginfo_from_user32 is called from rt_sigqueueinfo and
    rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
    of si_code.
    
    This fixes the following information leaks:
    x86:   8 bytes leaked when sending a signal from a 32-bit process to
           itself. This leak grows to 16 bytes if the process uses x32.
           (si_code = __SI_CHLD)
    x86:   100 bytes leaked when sending a signal from a 32-bit process to
           a 64-bit process. (si_code = -1)
    sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
           64-bit process. (si_code = any)
    
    parsic and s390 have similar bugs, but they are not vulnerable because
    rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
    to a different process.  These bugs are also fixed for consistency.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Chris Metcalf <cmetcalf@ezchip.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    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 16a49557bc101b804a0a74d4032556f8836b9469
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:29 2015 -0700

    signal: fix information leak in copy_siginfo_to_user
    
    commit 26135022f85105ad725cda103fa069e29e83bd16 upstream.
    
    This function may copy the si_addr_lsb, si_lower and si_upper fields to
    user mode when they haven't been initialized, which can leak kernel
    stack data to user mode.
    
    Just checking the value of si_code is insufficient because the same
    si_code value is shared between multiple signals.  This is solved by
    checking the value of si_signo in addition to si_code.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c233bffdb9ffd2c85d1f94ddd8be956ee2b353f
Author: Amanieu d'Antras <amanieu@gmail.com>
Date:   Thu Aug 6 15:46:33 2015 -0700

    signalfd: fix information leak in signalfd_copyinfo
    
    commit 3ead7c52bdb0ab44f4bb1feed505a8323cc12ba7 upstream.
    
    This function may copy the si_addr_lsb field to user mode when it hasn't
    been initialized, which can leak kernel stack data to user mode.
    
    Just checking the value of si_code is insufficient because the same
    si_code value is shared between multiple signals.  This is solved by
    checking the value of si_signo in addition to si_code.
    
    Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22ab6a2be78db078b11cc478bfc99cdc8e0642cb
Author: Fabio Estevam <festevam@gmail.com>
Date:   Fri Aug 16 12:55:56 2013 +0100

    ARM: 7819/1: fiq: Cast the first argument of flush_icache_range()
    
    commit 7cb3be0a27805c625ff7cce20c53c926d9483243 upstream.
    
    Commit 2ba85e7af4 (ARM: Fix FIQ code on VIVT CPUs) causes the following build warning:
    
    arch/arm/kernel/fiq.c:92:3: warning: passing argument 1 of 'cpu_cache.coherent_kern_range' makes integer from pointer without a cast [enabled by default]
    
    Cast it as '(unsigned long)base' to avoid the warning.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Martin Kaiser <lists@kaiser.cx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 627cd1579c7620dfc22e21173291ba0f0bab0cd0
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Aug 8 11:51:21 2013 +0100

    ARM: Fix FIQ code on VIVT CPUs
    
    commit 2ba85e7af4c639d933c9a87a6d7363f2983d5ada upstream.
    
    Aaro Koskinen reports the following oops:
    Installing fiq handler from c001b110, length 0x164
    Unable to handle kernel paging request at virtual address ffff1224
    pgd = c0004000
    [ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a
    ...
    [<c0013154>] (set_fiq_handler+0x0/0x6c) from [<c0365d38>] (ams_delta_init_fiq+0xa8/0x160)
     r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c
    [<c0365c90>] (ams_delta_init_fiq+0x0/0x160) from [<c0365b14>] (ams_delta_init+0xd4/0x114)
     r6:00000000 r5:fffece10 r4:c037a9e0
    [<c0365a40>] (ams_delta_init+0x0/0x114) from [<c03613b4>] (customize_machine+0x24/0x30)
    
    This is because the vectors page is now write-protected, and to change
    code in there we must write to its original alias.  Make that change,
    and adjust the cache flushing such that the code will become visible
    to the instruction stream on VIVT CPUs.
    
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Martin Kaiser <lists@kaiser.cx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28d4d6e9df9093d372896e76f14bc21faba7f544
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Aug 6 09:48:42 2013 +0100

    ARM: Fix !kuser helpers case
    
    commit 1b16c4bcf80e319b2226a886b72b8466179c8e3a upstream.
    
    Fix yet another build failure caused by a weird set of configuration
    settings:
    
      LD      init/built-in.o
    arch/arm/kernel/built-in.o: In function `__dabt_usr':
    /home/tom3q/kernel/arch/arm/kernel/entry-armv.S:377: undefined reference to `kuser_cmpxchg64_fixup'
    arch/arm/kernel/built-in.o: In function `__irq_usr':
    /home/tom3q/kernel/arch/arm/kernel/entry-armv.S:387: undefined reference to `kuser_cmpxchg64_fixup'
    
    caused by:
    CONFIG_KUSER_HELPERS=n
    CONFIG_CPU_32v6K=n
    CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG=n
    
    Reported-by: Tomasz Figa <tomasz.figa@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Martin Kaiser <lists@kaiser.cx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d0dd4350a4107265fd8701d4b26fdc033ad28cc
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Mar 21 20:08:18 2015 -0400

    sg_start_req(): make sure that there's not too many elements in iovec
    
    commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.
    
    unfortunately, allowing an arbitrary 16bit value means a possibility of
    overflow in the calculation of total number of pages in bio_map_user_iov() -
    we rely on there being no more than PAGE_SIZE members of sum in the
    first loop there.  If that sum wraps around, we end up allocating
    too small array of pointers to pages and it's easy to overflow it in
    the second loop.
    
    X-Coverup: TINC (and there's no lumber cartel either)
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
     fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
      that function.]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4a6d3f3491a55269ee1e8d99f6fa7bab15cc011
Author: NeilBrown <neilb@suse.com>
Date:   Mon Jul 27 11:48:52 2015 +1000

    md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
    
    commit 423f04d63cf421ea436bcc5be02543d549ce4b28 upstream.
    
    raid1_end_read_request() assumes that the In_sync bits are consistent
    with the ->degaded count.
    raid1_spare_active updates the In_sync bit before the ->degraded count
    and so exposes an inconsistency, as does error()
    So extend the spinlock in raid1_spare_active() and error() to hide those
    inconsistencies.
    
    This should probably be part of
      Commit: 34cab6f42003 ("md/raid1: fix test for 'was read error from
      last working device'.")
    as it addresses the same issue.  It fixes the same bug and should go
    to -stable for same reasons.
    
    Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a4cb7b52d728b1f6b76e73ea0277f422da1ffac
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Thu Aug 6 15:46:23 2015 -0700

    ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()
    
    commit 209f7512d007980fd111a74a064d70a3656079cf upstream.
    
    The "BUG_ON(list_empty(&osb->blocked_lock_list))" in
    ocfs2_downconvert_thread_do_work can be triggered in the following case:
    
    ocfs2dc has firstly saved osb->blocked_lock_count to local varibale
    processed, and then processes the dentry lockres.  During the dentry
    put, it calls iput and then deletes rw, inode and open lockres from
    blocked list in ocfs2_mark_lockres_freeing.  And this causes the
    variable `processed' to not reflect the number of blocked lockres to be
    processed, which triggers the BUG.
    
    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2934eb36cf564b6e368d8b43eb48384b308e04e7
Author: Marcus Gelderie <redmnic@gmail.com>
Date:   Thu Aug 6 15:46:10 2015 -0700

    ipc: modify message queue accounting to not take kernel data structures into account
    
    commit de54b9ac253787c366bbfb28d901a31954eb3511 upstream.
    
    A while back, the message queue implementation in the kernel was
    improved to use btrees to speed up retrieval of messages, in commit
    d6629859b36d ("ipc/mqueue: improve performance of send/recv").
    
    That patch introducing the improved kernel handling of message queues
    (using btrees) has, as a by-product, changed the meaning of the QSIZE
    field in the pseudo-file created for the queue.  Before, this field
    reflected the size of the user-data in the queue.  Since, it also takes
    kernel data structures into account.  For example, if 13 bytes of user
    data are in the queue, on my machine the file reports a size of 61
    bytes.
    
    There was some discussion on this topic before (for example
    https://lkml.org/lkml/2014/10/1/115).  Commenting on a th lkml, Michael
    Kerrisk gave the following background
    (https://lkml.org/lkml/2015/6/16/74):
    
        The pseudofiles in the mqueue filesystem (usually mounted at
        /dev/mqueue) expose fields with metadata describing a message
        queue. One of these fields, QSIZE, as originally implemented,
        showed the total number of bytes of user data in all messages in
        the message queue, and this feature was documented from the
        beginning in the mq_overview(7) page. In 3.5, some other (useful)
        work happened to break the user-space API in a couple of places,
        including the value exposed via QSIZE, which now includes a measure
        of kernel overhead bytes for the queue, a figure that renders QSIZE
        useless for its original purpose, since there's no way to deduce
        the number of overhead bytes consumed by the implementation.
        (The other user-space breakage was subsequently fixed.)
    
    This patch removes the accounting of kernel data structures in the
    queue.  Reporting the size of these data-structures in the QSIZE field
    was a breaking change (see Michael's comment above).  Without the QSIZE
    field reporting the total size of user-data in the queue, there is no
    way to deduce this number.
    
    It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
    against the worst-case size of the queue (in both the old and the new
    implementation).  Therefore, the kernel overhead accounting in QSIZE is
    not necessary to help the user understand the limitations RLIMIT imposes
    on the processes.
    
    Signed-off-by: Marcus Gelderie <redmnic@gmail.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
    Acked-by: Davidlohr Bueso <dbueso@suse.de>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: John Duffy <jb_duffy@btinternet.com>
    Cc: Arto Bendiken <arto@bendiken.net>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d6e58957cb833fe1847bd8370dac9b3939546b9
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Jul 25 03:03:38 2015 +0300

    ALSA: hda - fix cs4210_spdif_automute()
    
    commit 44008f0896ae205b02b0882dbf807f0de149efc4 upstream.
    
    Smatch complains that we have nested checks for "spdif_present".  It
    turns out the current behavior isn't correct, we should remove the first
    check and keep the second.
    
    Fixes: 1077a024812d ('ALSA: hda - Use generic parser for Cirrus codec driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 621468a3d79c2ef11ef2ec2eeb1038b8c4373b7d
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 22 23:14:19 2015 -0700

    iscsi-target: Fix iscsit_start_kthreads failure OOPs
    
    commit e54198657b65625085834847ab6271087323ffea upstream.
    
    This patch fixes a regression introduced with the following commit
    in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers
    a NULL pointer dereference OOPs:
    
        commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Thu Feb 26 22:19:15 2015 -0800
    
            iscsi-target: Convert iscsi_thread_set usage to kthread.h
    
    To address this bug, move iscsit_start_kthreads() immediately
    preceeding the transmit of last login response, before signaling
    a successful transition into full-feature-phase within existing
    iscsi_target_do_tx_login_io() logic.
    
    This ensures that no target-side resource allocation failures can
    occur after the final login response has been successfully sent.
    
    Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread
    to sleep to prevent other socket related failures until the final
    iscsi_post_login_handler() call is able to complete.
    
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Nicholas Bellinger <nab@daterainc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dff252b8499f7f7cb4353d5c64ed5dbc13b7daa0
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 16 17:36:11 2015 +0300

    rbd: fix copyup completion race
    
    commit 2761713d35e370fd640b5781109f753066b746c4 upstream.
    
    For write/discard obj_requests that involved a copyup method call, the
    opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
    rbd_img_obj_copyup_callback().  The latter frees copyup pages, sets
    ->xferred and delegates to rbd_img_obj_callback(), the "normal" image
    object callback, for reporting to block layer and putting refs.
    
    rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
    which means obj_request is marked done in rbd_osd_trivial_callback(),
    *before* ->callback is invoked and rbd_img_obj_copyup_callback() has
    a chance to run.  Marking obj_request done essentially means giving
    rbd_img_obj_callback() a license to end it at any moment, so if another
    obj_request from the same img_request is being completed concurrently,
    rbd_img_obj_end_request() may very well be called on such prematurally
    marked done request:
    
    <obj_request-1/2 reply>
    handle_reply()
      rbd_osd_req_callback()
        rbd_osd_trivial_callback()
        rbd_obj_request_complete()
        rbd_img_obj_copyup_callback()
        rbd_img_obj_callback()
                                        <obj_request-2/2 reply>
                                        handle_reply()
                                          rbd_osd_req_callback()
                                            rbd_osd_trivial_callback()
          for_each_obj_request(obj_request->img_request) {
            rbd_img_obj_end_request(obj_request-1/2)
            rbd_img_obj_end_request(obj_request-2/2) <--
          }
    
    Calling rbd_img_obj_end_request() on such a request leads to trouble,
    in particular because its ->xfferred is 0.  We report 0 to the block
    layer with blk_update_request(), get back 1 for "this request has more
    data in flight" and then trip on
    
        rbd_assert(more ^ (which == img_request->obj_request_count));
    
    with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
    been called for both requests and lhs (more) being 1 because we haven't
    got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
    
    To fix this, leverage that rbd wants to call class methods in only two
    cases: one is a generic method call wrapper (obj_request is standalone)
    and the other is a copyup (obj_request is part of an img_request).  So
    make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
    rbd_img_obj_copyup_callback() from it if obj_request is part of an
    img_request, similar to how CEPH_OSD_OP_READ handler invokes
    rbd_img_obj_request_read_callback().
    
    Since rbd_img_obj_copyup_callback() is now being called from the OSD
    request callback (only), it is renamed to rbd_osd_copyup_callback().
    
    Cc: Alex Elder <elder@linaro.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3646ba72fd7292e9166866aed65e6e8de4b6440
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Jul 22 18:05:35 2015 +0800

    crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer
    
    commit f898c522f0e9ac9f3177d0762b76e2ab2d2cf9c0 upstream.
    
    This patch removes a bogus BUG_ON in the ablkcipher path that
    triggers when the destination buffer is different from the source
    buffer and is scattered.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 292f53675e097ca807df744fb6fd39211a134bf7
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Fri Jun 26 03:28:24 2015 +0200

    xen/gntdevt: Fix race condition in gntdev_release()
    
    commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.
    
    While gntdev_release() is called the MMU notifier is still registered
    and can traverse priv->maps list even if no pages are mapped (which is
    the case -- gntdev_release() is called after all). But
    gntdev_release() will clear that list, so make sure that only one of
    those things happens at the same time.
    
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f2c206ae6f9e1005ac7f092e8d65c17307a0d59
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Jul 30 14:31:31 2015 -0700

    x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
    
    commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
    
    The update_va_mapping hypercall can fail if the VA isn't present
    in the guest's page tables.  Under certain loads, this can
    result in an OOPS when the target address is in unpopulated vmap
    space.
    
    While we're at it, add comments to help explain what's going on.
    
    This isn't a great long-term fix.  This code should probably be
    changed to use something like set_memory_ro.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: David Vrabel <dvrabel@cantab.net>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Jan Beulich <jbeulich@suse.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: security@kernel.org <security@kernel.org>
    Cc: xen-devel <xen-devel@lists.xen.org>
    Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 683d1a7fb35595d094f0de2f130e7314ee1978f3
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 6 19:13:25 2015 -0700

    sparc64: Fix userspace FPU register corruptions.
    
    [ Upstream commit 44922150d87cef616fd183220d43d8fde4d41390 ]
    
    If we have a series of events from userpsace, with %fprs=FPRS_FEF,
    like follows:
    
    ETRAP
    	ETRAP
    		VIS_ENTRY(fprs=0x4)
    		VIS_EXIT
    		RTRAP (kernel FPU restore with fpu_saved=0x4)
    	RTRAP
    
    We will not restore the user registers that were clobbered by the FPU
    using kernel code in the inner-most trap.
    
    Traps allocate FPU save slots in the thread struct, and FPU using
    sequences save the "dirty" FPU registers only.
    
    This works at the initial trap level because all of the registers
    get recorded into the top-level FPU save area, and we'll return
    to userspace with the FPU disabled so that any FPU use by the user
    will take an FPU disabled trap wherein we'll load the registers
    back up properly.
    
    But this is not how trap returns from kernel to kernel operate.
    
    The simplest fix for this bug is to always save all FPU register state
    for anything other than the top-most FPU save area.
    
    Getting rid of the optimized inner-slot FPU saving code ends up
    making VISEntryHalf degenerate into plain VISEntry.
    
    Longer term we need to do something smarter to reinstate the partial
    save optimizations.  Perhaps the fundament error is having trap entry
    and exit allocate FPU save slots and restore register state.  Instead,
    the VISEntry et al. calls should be doing that work.
    
    This bug is about two decades old.
    
    Reported-by: James Y Knight <jyknight@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2312fd49eba5795907327885b407d321ea9cca54
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Oct 14 19:37:58 2014 -0700

    sparc64: Fix FPU register corruption with AES crypto offload.
    
    [ Upstream commit f4da3628dc7c32a59d1fb7116bb042e6f436d611 ]
    
    The AES loops in arch/sparc/crypto/aes_glue.c use a scheme where the
    key material is preloaded into the FPU registers, and then we loop
    over and over doing the crypt operation, reusing those pre-cooked key
    registers.
    
    There are intervening blkcipher*() calls between the crypt operation
    calls.  And those might perform memcpy() and thus also try to use the
    FPU.
    
    The sparc64 kernel FPU usage mechanism is designed to allow such
    recursive uses, but with a catch.
    
    There has to be a trap between the two FPU using threads of control.
    
    The mechanism works by, when the FPU is already in use by the kernel,
    allocating a slot for FPU saving at trap time.  Then if, within the
    trap handler, we try to use the FPU registers, the pre-trap FPU
    register state is saved into the slot.  Then at trap return time we
    notice this and restore the pre-trap FPU state.
    
    Over the long term there are various more involved ways we can make
    this work, but for a quick fix let's take advantage of the fact that
    the situation where this happens is very limited.
    
    All sparc64 chips that support the crypto instructiosn also are using
    the Niagara4 memcpy routine, and that routine only uses the FPU for
    large copies where we can't get the source aligned properly to a
    multiple of 8 bytes.
    
    We look to see if the FPU is already in use in this context, and if so
    we use the non-large copy path which only uses integer registers.
    
    Furthermore, we also limit this special logic to when we are doing
    kernel copy, rather than a user copy.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8231988d46318b1039f057b78df6c9630e96f4
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue May 21 13:05:37 2013 +0200

    perf/x86/amd: Rework AMD PMU init code
    
    commit 1b45adcd9a503428e6de6b39bc6892d86c9c1d41 upstream.
    
    Josh reported that his QEMU is a bad hardware emulator and trips a
    WARN in the AMD PMU init code. He requested the WARN be turned into a
    pr_err() or similar.
    
    While there, rework the code a little.
    
    Reported-by: Josh Boyer <jwboyer@redhat.com>
    Acked-by: Robert Richter <rric@kernel.org>
    Acked-by: Jacob Shin <jacob.shin@amd.com>
    Cc: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130521110537.GG26912@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14c99cd5cdd34ee464eeb1fc9f0d560672a4f2ec
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Sep 8 00:25:36 2013 -0700

    mfd: sm501: dbg_regs attribute must be read-only
    
    commit 8a8320c2e78d1b619a8fa8eb5ae946b8691de604 upstream.
    
    Fix:
    
    sm501 sm501: SM501 At b3e00000: Version 050100a0, 8 Mb, IRQ 100
    Attribute dbg_regs: write permission without 'store'
    ------------[ cut here ]------------
    WARNING: at drivers/base/core.c:620
    
    dbg_regs does not have a write function and must therefore be marked
    as read-only.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 471bfba87fb46dad486fe0b9aa4a14c2038383b7
Author: Xie XiuQi <xiexiuqi@huawei.com>
Date:   Fri Jan 24 14:00:52 2014 -0600

    ipmi: fix timeout calculation when bmc is disconnected
    
    commit e21404dc0ac7ac971c1e36274b48bb460463f4e5 upstream.
    
    Loading ipmi_si module while bmc is disconnected, we found the timeout
    is longer than 5 secs.  Actually it takes about 3 mins and 20
    secs.(HZ=250)
    
    error message as below:
      Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
      Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
      [...]
      Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
      Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
      Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
      Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]
    
    Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
    sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
    usecs from timeout.
    
    Reported-by: Hu Shiyuan <hushiyuan@huawei.com>
    Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21c7d3807a429ba6c606e30087d785c0ef3d6288
Author: Benjamin Randazzo <benjamin@randazzo.fr>
Date:   Sat Jul 25 16:36:50 2015 +0200

    md: use kzalloc() when bitmap is disabled
    
    commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
    
    In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
    mdu_bitmap_file_t called "file".
    
    5769         file = kmalloc(sizeof(*file), GFP_NOIO);
    5770         if (!file)
    5771                 return -ENOMEM;
    
    This structure is copied to user space at the end of the function.
    
    5786         if (err == 0 &&
    5787             copy_to_user(arg, file, sizeof(*file)))
    5788                 err = -EFAULT
    
    But if bitmap is disabled only the first byte of "file" is initialized
    with zero, so it's possible to read some bytes (up to 4095) of kernel
    space memory from user space. This is an information leak.
    
    5775         /* bitmap disabled, zero the first byte and copy out */
    5776         if (!mddev->bitmap_info.file)
    5777                 file->pathname[0] = '\0';
    
    Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e850ac8e566a530291d3c6d023030b3ea4a5d48e
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Mon Jul 27 08:56:05 2015 +0200

    USB: sierra: add 1199:68AB device ID
    
    commit 74472233233f577eaa0ca6d6e17d9017b6e53150 upstream.
    
    Add support for the Sierra Wireless AR8550 device with
    USB descriptor 0x1199, 0x68AB.
    
    It is common with MC879x modules 1199:683c/683d which
    also are composite devices with 7 interfaces (0..6)
    and also MDM62xx based as the AR8550.
    
    The major difference are only the interface attributes
    02/02/01 on interfaces 3 and 4 on the AR8550. They are
    vendor specific ff/ff/ff on MC879x modules.
    
    lsusb reports:
    
    Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x1199 Sierra Wireless, Inc.
      idProduct          0x68ab
      bcdDevice            0.06
      iManufacturer           3 Sierra Wireless, Incorporated
      iProduct                2 AR8550
      iSerial                 0
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength          198
        bNumInterfaces          7
        bConfigurationValue     1
        iConfiguration          1 Sierra Configuration
        bmAttributes         0xe0
          Self Powered
          Remote Wakeup
        MaxPower                0mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        2
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x03  EP 3 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        3
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x84  EP 4 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x85  EP 5 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x04  EP 4 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        4
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x86  EP 6 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x87  EP 7 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x05  EP 5 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        5
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x88  EP 8 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x89  EP 9 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x06  EP 6 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        6
          bAlternateSetting       0
          bNumEndpoints           3
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass    255 Vendor Specific Subclass
          bInterfaceProtocol    255 Vendor Specific Protocol
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x8a  EP 10 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               5
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x8b  EP 11 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x07  EP 7 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval              32
    Device Qualifier (for other device speed):
      bLength                10
      bDescriptorType         6
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      bNumConfigurations      1
    Device Status:     0x0001
      Self Powered
    
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    Cc: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0f94181a75400886041b183287ba91f1f392492
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Aug 3 16:07:48 2015 +0300

    xhci: fix off by one error in TRB DMA address boundary check
    
    commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd upstream.
    
    We need to check that a TRB is part of the current segment
    before calculating its DMA address.
    
    Previously a ring segment didn't use a full memory page, and every
    new ring segment got a new memory page, so the off by one
    error in checking the upper bound was never seen.
    
    Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
    didn't catch the case when a TRB was the first element of the next segment.
    
    This is triggered if the virtual memory pages for a ring segment are
    next to each in increasing order where the ring buffer wraps around and
    causes errors like:
    
    [  106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
    [  106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
    
    The trb-end address is one outside the end-seg address.
    
    Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a1310da4aaeace4accce0762af56625bfbd769
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:33 2015 -0500

    ipr: Fix invalid array indexing for HRRQ
    
    commit 3f1c0581310d5d94bd72740231507e763a6252a4 upstream.
    
    Fixes another signed / unsigned array indexing bug in the ipr driver.
    Currently, when hrrq_index wraps, it becomes a negative number. We
    do the modulo, but still have a negative number, so we end up indexing
    backwards in the array. Given where the hrrq array is located in memory,
    we probably won't actually reference memory we don't own, but nonetheless
    ipr is still looking at data within struct ipr_ioa_cfg and interpreting it as
    struct ipr_hrr_queue data, so bad things could certainly happen.
    
    Each ipr adapter has anywhere from 1 to 16 HRRQs. By default, we use 2 on new
    adapters.  Let's take an example:
    
    Assume ioa_cfg->hrrq_index=0x7fffffffe and ioa_cfg->hrrq_num=4:
    
    The atomic_add_return will then return -1. We mod this with 3 and get -2, add
    one and get -1 for an array index.
    
    On adapters which support more than a single HRRQ, we dedicate HRRQ to adapter
    initialization and error interrupts so that we can optimize the other queues
    for fast path I/O. So all normal I/O uses HRRQ 1-15. So we want to spread the
    I/O requests across those HRRQs.
    
    With the default module parameter settings, this bug won't hit, only when
    someone sets the ipr.number_of_msix parameter to a value larger than 3 is when
    bad things start to happen.
    
    Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 615b0eb835d3d37a9339872c5c1f7ce299e7a40f
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:31 2015 -0500

    ipr: Fix incorrect trace indexing
    
    commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 upstream.
    
    When ipr's internal driver trace was changed to an atomic, a signed/unsigned
    bug slipped in which results in us indexing backwards in our memory buffer
    writing on memory that does not belong to us. This patch fixes this by removing
    the modulo and instead just mask off the low bits.
    
    Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec8ea7c221488d7e6a05a34e2f9fafab6f39c976
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Jul 14 11:41:29 2015 -0500

    ipr: Fix locking for unit attention handling
    
    commit 36b8e180e1e929e00b351c3b72aab3147fc14116 upstream.
    
    Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
    a crash seen as the __devices list in the scsi host was changing as we were
    iterating through it.
    
    Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f1a904ec548e48e7daa7b54fe18664d5a7e0d44
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jul 27 19:24:31 2015 -0400

    drm/radeon/combios: add some validation of lvds values
    
    commit 0a90a0cff9f429f886f423967ae053150dce9259 upstream.
    
    Fixes a broken hsync start value uncovered by:
    abc0b1447d4974963548777a5ba4a4457c82c426
    (drm: Perform basic sanity checks on probed modes)
    
    The driver handled the bad hsync start elsewhere, but
    the above commit prevented it from getting added.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=91401
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36db20aee5f89a3e23cca351841214d7d9aa4e8b
Author: Jan Kara <jack@suse.com>
Date:   Thu Aug 6 15:46:42 2015 -0700

    fsnotify: fix oops in fsnotify_clear_marks_by_group_flags()
    
    commit 8f2f3eb59dff4ec538de55f2e0592fec85966aab upstream.
    
    fsnotify_clear_marks_by_group_flags() can race with
    fsnotify_destroy_marks() so that when fsnotify_destroy_mark_locked()
    drops mark_mutex, a mark from the list iterated by
    fsnotify_clear_marks_by_group_flags() can be freed and thus the next
    entry pointer we have cached may become stale and we dereference free
    memory.
    
    Fix the problem by first moving marks to free to a special private list
    and then always free the first entry in the special list.  This method
    is safe even when entries from the list can disappear once we drop the
    lock.
    
    Signed-off-by: Jan Kara <jack@suse.com>
    Reported-by: Ashish Sangwan <a.sangwan@samsung.com>
    Reviewed-by: Ashish Sangwan <a.sangwan@samsung.com>
    Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c45e0a863527d466a3bc91d039471c0182f8fee1
Author: David Daney <david.daney@cavium.com>
Date:   Mon Aug 3 17:48:43 2015 -0700

    MIPS: Make set_pte() SMP safe.
    
    commit 46011e6ea39235e4aca656673c500eac81a07a17 upstream.
    
    On MIPS the GLOBAL bit of the PTE must have the same value in any
    aligned pair of PTEs.  These pairs of PTEs are referred to as
    "buddies".  In a SMP system is is possible for two CPUs to be calling
    set_pte() on adjacent PTEs at the same time.  There is a race between
    setting the PTE and a different CPU setting the GLOBAL bit in its
    buddy PTE.
    
    This race can be observed when multiple CPUs are executing
    vmap()/vfree() at the same time.
    
    Make setting the buddy PTE's GLOBAL bit an atomic operation to close
    the race condition.
    
    The case of CONFIG_64BIT_PHYS_ADDR && CONFIG_CPU_MIPS32 is *not*
    handled.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/10835/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff26891febc84e3e253b3f67bafd5cdf16f6a795
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Jul 19 00:38:41 2015 +0200

    MIPS: Fix sched_getaffinity with MT FPAFF enabled
    
    commit 1d62d737555e1378eb62a8bba26644f7d97139d2 upstream.
    
    p->thread.user_cpus_allowed is zero-initialized and is only filled on
    the first sched_setaffinity call.
    
    To avoid adding overhead in the task initialization codepath, simply OR
    the returned mask in sched_getaffinity with p->cpus_allowed.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/10740/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6025624e42dd86d4174ed5ccd122b86c100995d8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Mar 16 21:00:25 2014 +0100

    ARM: realview: fix sparsemem build
    
    commit dd94d3558947756b102b1487911acd925224a38c upstream.
    
    Commit b713aa0b15 "ARM: fix asm/memory.h build error" broke some
    configurations on mach-realview with sparsemem enabled, which
    is missing a definition of PHYS_OFFSET:
    
    arch/arm/include/asm/memory.h:268:42: error: 'PHYS_OFFSET' undeclared (first use in this function)
     #define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
    arch/arm/include/asm/dma-mapping.h:104:9: note: in expansion of macro 'PHYS_PFN_OFFSET'
      return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
    
    An easy workaround is for realview to define PHYS_OFFSET itself,
    in the same way we define it for platforms that don't have a private
    __virt_to_phys function.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>