commit cd99a4f3f43ba1b88ff0ef01a9d5564fdf824c38 Author: Greg Kroah-Hartman Date: Sat Sep 2 07:07:05 2017 +0200 Linux 4.4.86 commit c81c4d453edf242af644f7e71f673fc7632f337c Author: Greg Kroah-Hartman Date: Thu Aug 31 08:30:43 2017 +0200 drm/i915: fix compiler warning in drivers/gpu/drm/i915/intel_uncore.c When building with gcc-7, the following warning happens: drivers/gpu/drm/i915/intel_uncore.c: In function ‘hsw_unclaimed_reg_detect’: drivers/gpu/drm/i915/intel_uncore.c:638:36: warning: decrement of a boolean expression [-Wbool-operation] i915.mmio_debug = mmio_debug_once--; ^~ As it's really not wise to -- on a boolean value. Commit 7571494004d8 ("drm/i915: Do one shot unclaimed mmio detection less frequently") which showed up in 4.6-rc1 does solve this issue, by rewriting the mmio detection logic, but that isn't really good to backport to 4.4-stable, so just fix up the obvious logic here to do the right thing. Cc: Chris Wilson Cc: Paulo Zanoni Cc: Mika Kuoppala Signed-off-by: Greg Kroah-Hartman commit b7571624fe986aecc7f42b421286f90cd7c67d6e Author: Hannes Reinecke 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 Reviewed-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Cc: Todd Poynor Signed-off-by: Greg Kroah-Hartman commit a4075bbb67b9562b9599affc6fb38f04bd7073ff Author: Hannes Reinecke 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 Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman [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 Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Todd Poynor Signed-off-by: Greg Kroah-Hartman commit 823086b057aabde5659c5f8638051613cba86247 Author: Dave Martin 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 Signed-off-by: Dave Martin Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 218720fe593965cb2bb45c3e463bb9991ceca40c Author: Arnd Bergmann 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 Signed-off-by: Arnd Bergmann Acked-by: Linus Torvalds Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tom Lendacky 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 Signed-off-by: Greg Kroah-Hartman commit a7a074f3a4d547a525748bfde179c4eb787d4f47 Author: Mark Rutland 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 Cc: Laura Abbott Reviewed-by: Steve Capper Tested-by: Steve Capper Reviewed-by: James Morse Tested-by: James Morse Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit da981044d049d1ec3bf454868aa44602e1df8582 Author: James Smart Date: Thu Mar 31 14:12:31 2016 -0700 lpfc: Fix Device discovery failures during switch reboot test. commit 342b59caa66240b670285d519fdfe2c44289b516 upstream. When the switch is rebooted, the lpfc driver fails to log into the fabric, and Unexpected timeout message is seen. Fix: Do not issue RegVFI if the FLOGI was internally aborted. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Guilherme G. Piccoli Signed-off-by: Greg Kroah-Hartman commit 389328ea1379e14e8bd8678af96d7a83bc1514e5 Author: Jiri Slaby 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 Cc: Christian Lamparter Cc: Kalle Valo Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 5acdbe667cf467cefb8fc13ded0ecca58dd9a761 Author: Javier González Date: Thu Jul 7 09:54:09 2016 +0200 lightnvm: initialize ppa_addr in dev_to_generic_addr() commit 5389a1dfb39786df08d4f6a482bd2734b1b50e33 upstream. The ->reserved bit is not initialized when allocated on stack. This may lead targets to misinterpret the PPA as cached. Signed-off-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d255fffdb532caf103369a5894be942e528c3151 Author: Martin Liska 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 Acked-by: Peter Oberparleiter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2f3e97a814c8f906d3334c85271aacb7a8783490 Author: Florian Meier Date: Thu Jul 14 12:07:26 2016 -0700 gcov: add support for gcc version >= 6 commit d02038f972538b93011d78c068f44514fbde0a8c upstream. Link: http://lkml.kernel.org/r/20160701130914.GA23225@styxhp Signed-off-by: Florian Meier Reviewed-by: Peter Oberparleiter Tested-by: Peter Oberparleiter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 41685ae5cd7bc51f8d796135611e7862f772ed19 Author: Wolfram Sang Date: Sun Jun 5 11:41:42 2016 +0200 i2c: jz4780: drop superfluous init commit 27bfeb5a0619554d9734fb39e14f0e80fa7c342c upstream. David reported that the length for memset was incorrect (element sizes were not taken into account). Then I saw that we are clearing kzalloced memory, so we can simply drop this code. Reported-by: David Binderman Reviewed-by: Axel Lin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 05429bbfd726ec0070a2381d8ae186b6899d2ae1 Author: Colin Ian King Date: Tue Jan 19 00:05:28 2016 +0000 btrfs: remove duplicate const specifier commit fb75d857a31d600cc0c37b8c7d914014f7fa3f9a upstream. duplicate const is redundant so remove it Signed-off-by: Colin Ian King Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9a64425945a0c8698e36ed55354db1245982c052 Author: Takashi Iwai Date: Thu May 12 18:04:16 2016 +0200 ALSA: au88x0: Fix zero clear of stream->resources commit 639db596165746ca87bbcb56559b094fd9042890 upstream. There are a few calls of memset() to stream->resources, but they all are called in a wrong size, sizeof(unsigned char) * VORTEX_RESOURCE_LAST, while this field is a u32 array. This may leave the memories not zero-cleared. Fix it by replacing them with a simpler sizeof(stream->resources) instead. Reported-by: David Binderman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit da8477a6695afe14070267b885e0bc3788d0d34a Author: Arnd Bergmann 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 Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman