commit 458ca52f1564938c158d271f45bce0bc6ede2b3f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 2 07:08:05 2017 +0200

    Linux 4.9.47

commit 529ada21ff9e37a14fd02ab1fb9d58d71d7a0d9e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 31 09:09:54 2017 +0200

    lz4: fix bogus gcc warning
    
    When building lz4 under gcc-7 we get the following bogus warning:
    
      CC [M]  lib/lz4/lz4hc_compress.o
    lib/lz4/lz4hc_compress.c: In function ‘lz4hc_compress’:
    lib/lz4/lz4hc_compress.c:179:42: warning: ‘delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
        chaintable[(size_t)(ptr) & MAXD_MASK] = delta;
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
    lib/lz4/lz4hc_compress.c:134:6: note: ‘delta’ was declared here
      u16 delta;
          ^~~~~
    
    This doesn't show up in the 4.4-stable tree due to us turning off
    warnings like this.  It also doesn't show up in newer kernel versions as
    this code was totally rewritten.
    
    So for now, to get the 4.9-stable tree to build with 0 warnings on x86
    allmodconfig, let's just shut the compiler up by initializing the
    variable to 0, despite it not really doing anything.
    
    To be far, this code is crazy complex, so the fact that gcc can't
    determine if the variable is really used or not isn't that bad, I'd
    blame the code here instead of the compiler.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c47c52cde806f32c4da1e455874f6aa154c06aca
Author: Hannes Reinecke <hare@suse.de>
Date:   Mon Apr 24 10:26:36 2017 +0200

    scsi: sg: reset 'res_in_use' after unlinking reserved array
    
    commit e791ce27c3f6a1d3c746fd6a8f8e36c9540ec6f9 upstream.
    
    Once the reserved page array is unused we can reset the 'res_in_use'
    state; here we can do a lazy update without holding the mutex as we only
    need to check against concurrent access, not concurrent release.
    
    [mkp: checkpatch]
    
    Fixes: 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page array")
    Signed-off-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Todd Poynor <toddpoynor@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4099ac93838537351099859f824b8c3f9451a264
Author: Hannes Reinecke <hare@suse.de>
Date:   Fri Apr 7 09:34:14 2017 +0200

    scsi: sg: protect accesses to 'reserved' page array
    
    commit 1bc0eb0446158cc76562176b80623aa119afee5b upstream.
    
    The 'reserved' page array is used as a short-cut for mapping data,
    saving us to allocate pages per request. However, the 'reserved' array
    is only capable of holding one request, so this patch introduces a mutex
    for protect 'sg_fd' against concurrent accesses.
    
    Signed-off-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    [toddpoynor@google.com: backport to 3.18-4.9,  fixup for bad ioctl
    SG_SET_FORCE_LOW_DMA code removed in later versions and not modified by
    the original patch.]
    
    Signed-off-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Todd Poynor <toddpoynor@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0c6dff9230398dd7ec9ca6c1c023c8bd44bb6cd
Author: Waiman Long <longman@redhat.com>
Date:   Wed Feb 8 14:46:48 2017 -0500

    locking/spinlock/debug: Remove spinlock lockup detection code
    
    commit bc88c10d7e6900916f5e1ba3829d66a9de92b633 upstream.
    
    The current spinlock lockup detection code can sometimes produce false
    positives because of the unfairness of the locking algorithm itself.
    
    So the lockup detection code is now removed. Instead, we are relying
    on the NMI watchdog to detect potential lockup. We won't have lockup
    detection if the watchdog isn't running.
    
    The commented-out read-write lock lockup detection code are also
    removed.
    
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1486583208-11038-1-git-send-email-longman@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27e7506c33d0f8afc1b49566e8994028a2847072
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Fri Aug 18 16:57:01 2017 +0100

    arm64: fpsimd: Prevent registers leaking across exec
    
    commit 096622104e14d8a1db4860bd557717067a0515d2 upstream.
    
    There are some tricky dependencies between the different stages of
    flushing the FPSIMD register state during exec, and these can race
    with context switch in ways that can cause the old task's regs to
    leak across.  In particular, a context switch during the memset() can
    cause some of the task's old FPSIMD registers to reappear.
    
    Disabling preemption for this small window would be no big deal for
    performance: preemption is already disabled for similar scenarios
    like updating the FPSIMD registers in sigreturn.
    
    So, instead of rearranging things in ways that might swap existing
    subtle bugs for new ones, this patch just disables preemption
    around the FPSIMD state flushing so that races of this type can't
    occur here.  This brings fpsimd_flush_thread() into line with other
    code paths.
    
    Fixes: 674c242c9323 ("arm64: flush FP/SIMD state correctly after execve()")
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43f776dab360931f3dd344c8f4fb28b52ea98ee9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:02 2017 +0200

    x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl
    
    commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.
    
    The x86 version of insb/insw/insl uses an inline assembly that does
    not have the target buffer listed as an output. This can confuse
    the compiler, leading it to think that a subsequent access of the
    buffer is uninitialized:
    
      drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
      drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
      drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/sb1000.c: In function 'sb1000_rx':
      drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
      drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    I tried to mark the exact input buffer as an output here, but couldn't
    figure it out. As suggested by Linus, marking all memory as clobbered
    however is good enough too. For the outs operations, I also add the
    memory clobber, to force the input to be written to local variables.
    This is probably already guaranteed by the "asm volatile", but it can't
    hurt to do this for symmetry.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
    Link: https://lkml.org/lkml/2017/7/12/605
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 509d8b52bbe7e6f6022a086989e7ecf5180508cc
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jul 11 15:19:22 2017 +0100

    arm64: mm: abort uaccess retries upon fatal signal
    
    commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.
    
    When there's a fatal signal pending, arm64's do_page_fault()
    implementation returns 0. The intent is that we'll return to the
    faulting userspace instruction, delivering the signal on the way.
    
    However, if we take a fatal signal during fixing up a uaccess, this
    results in a return to the faulting kernel instruction, which will be
    instantly retried, resulting in the same fault being taken forever. As
    the task never reaches userspace, the signal is not delivered, and the
    task is left unkillable. While the task is stuck in this state, it can
    inhibit the forward progress of the system.
    
    To avoid this, we must ensure that when a fatal signal is pending, we
    apply any necessary fixup for a faulting kernel instruction. Thus we
    will return to an error path, and it is up to that code to make forward
    progress towards delivering the fatal signal.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Reviewed-by: Steve Capper <steve.capper@arm.com>
    Tested-by: Steve Capper <steve.capper@arm.com>
    Reviewed-by: James Morse <james.morse@arm.com>
    Tested-by: James Morse <james.morse@arm.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e033635b2b7eab01855c5a3e426e364064fd12b
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Wed May 3 15:17:51 2017 +0100

    kvm: arm/arm64: Fix race in resetting stage2 PGD
    
    commit 6c0d706b563af732adb094c5bf807437e8963e84 upstream.
    
    In kvm_free_stage2_pgd() we check the stage2 PGD before holding
    the lock and proceed to take the lock if it is valid. And we unmap
    the page tables, followed by releasing the lock. We reset the PGD
    only after dropping this lock, which could cause a race condition
    where another thread waiting on or even holding the lock, could
    potentially see that the PGD is still valid and proceed to perform
    a stage2 operation and later encounter a NULL PGD.
    
    [223090.242280] Unable to handle kernel NULL pointer dereference at
    virtual address 00000040
    [223090.262330] PC is at unmap_stage2_range+0x8c/0x428
    [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
    [223090.262531] Call trace:
    [223090.262533] [<ffff0000080adb78>] unmap_stage2_range+0x8c/0x428
    [223090.262535] [<ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c
    [223090.262537] [<ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104
    [223090.262539] [<ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc
    [223090.262543] [<ffff0000080a2478>]
    kvm_mmu_notifier_invalidate_page+0x50/0x8c
    [223090.262547] [<ffff0000082274f8>]
    __mmu_notifier_invalidate_page+0x5c/0x84
    [223090.262551] [<ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0
    [223090.262553] [<ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0
    [223090.262555] [<ffff00000820c90c>] try_to_unmap+0x74/0xa4
    [223090.262557] [<ffff000008230ce4>] migrate_pages+0x31c/0x5ac
    [223090.262561] [<ffff0000081f869c>] compact_zone+0x3fc/0x7ac
    [223090.262563] [<ffff0000081f8ae0>] compact_zone_order+0x94/0xb0
    [223090.262564] [<ffff0000081f91c0>] try_to_compact_pages+0x108/0x290
    [223090.262569] [<ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac
    [223090.262571] [<ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4
    [223090.262572] [<ffff0000082256f0>] alloc_pages_vma+0x230/0x254
    [223090.262574] [<ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538
    [223090.262576] [<ffff000008201bec>] handle_mm_fault+0xd40/0x17a4
    [223090.262577] [<ffff0000081fb324>] __get_user_pages+0x12c/0x36c
    [223090.262578] [<ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8
    [223090.262579] [<ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c
    [223090.262580] [<ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c
    [223090.262582] [<ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774
    [223090.262584] [<ffff0000080b2bac>] handle_exit+0x11c/0x1ac
    [223090.262586] [<ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648
    [223090.262587] [<ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768
    [223090.262590] [<ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4
    [223090.262591] [<ffff00000825e26c>] SyS_ioctl+0x90/0xa4
    [223090.262595] [<ffff000008085d84>] el0_svc_naked+0x38/0x3c
    
    This patch moves the stage2 PGD manipulation under the lock.
    
    Reported-by: Alexander Graf <agraf@suse.de>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a1532b16fd49596304e1cfd285cf4509b6fba7
Author: Martin Liska <mliska@suse.cz>
Date:   Fri May 12 15:46:35 2017 -0700

    gcov: support GCC 7.1
    
    commit 05384213436ab690c46d9dfec706b80ef8d671ab upstream.
    
    Starting from GCC 7.1, __gcov_exit is a new symbol expected to be
    implemented in a profiling runtime.
    
    [akpm@linux-foundation.org: coding-style fixes]
    [mliska@suse.cz: v2]
      Link: http://lkml.kernel.org/r/e63a3c59-0149-c97e-4084-20ca8f146b26@suse.cz
    Link: http://lkml.kernel.org/r/8c4084fa-3885-29fe-5fc4-0d4ca199c785@suse.cz
    Signed-off-by: Martin Liska <mliska@suse.cz>
    Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.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 47974403c9caadc9fdb762e399569689efb02386
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 16 16:07:10 2016 +0100

    staging: wilc1000: simplify vif[i]->ndev accesses
    
    commit 735bb39ca3bed8469b3b3a42d8cc57bdb9fc4dd7 upstream.
    
    With gcc-7, I got a new warning for this driver:
    
    wilc1000/linux_wlan.c: In function 'wilc_netdev_cleanup':
    wilc1000/linux_wlan.c:1224:15: error: 'vif[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    wilc1000/linux_wlan.c:1224:15: error: 'vif[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    A closer look at the function reveals that it's more complex than
    it needs to be, given that based on how the device is created
    we always get
    
            netdev_priv(vif->ndev) == vif
    
    Based on this assumption, I found a few other places in the same file
    that can be simplified. That code appears to be a relic from times
    when the assumption above was not valid.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd758f82a3bf2f11843a59188cd0d7922dbcc731
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 18 17:14:01 2016 +0100

    scsi: isci: avoid array subscript warning
    
    commit 5cfa2a3c7342bd0b50716c8bb32ee491af43c785 upstream.
    
    I'm getting a new warning with gcc-7:
    
    isci/remote_node_context.c: In function 'sci_remote_node_context_destruct':
    isci/remote_node_context.c:69:16: error: array subscript is above array bounds [-Werror=array-bounds]
    
    This is odd, since we clearly cover all values for enum
    scis_sds_remote_node_context_states here. Anyway, checking for an array
    overflow can't harm and it makes the warning go away.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f71996c3ce5d3b7ee0f581f6c2c37a19d50d72e8
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Oct 14 11:23:09 2016 +0200

    p54: memset(0) whole array
    
    commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.
    
    gcc 7 complains:
    drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
    drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
    
    Fix that by passing the correct size to memset.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Christian Lamparter <chunkeey@googlemail.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Acked-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>