--- /dev/null
+From d76036ab47eafa6ce52b69482e91ca3ba337d6d6 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 15 Aug 2017 13:00:36 +0200
+Subject: audit: Fix use after free in audit_remove_watch_rule()
+
+From: Jan Kara <jack@suse.cz>
+
+commit d76036ab47eafa6ce52b69482e91ca3ba337d6d6 upstream.
+
+audit_remove_watch_rule() drops watch's reference to parent but then
+continues to work with it. That is not safe as parent can get freed once
+we drop our reference. The following is a trivial reproducer:
+
+mount -o loop image /mnt
+touch /mnt/file
+auditctl -w /mnt/file -p wax
+umount /mnt
+auditctl -D
+<crash in fsnotify_destroy_mark()>
+
+Grab our own reference in audit_remove_watch_rule() earlier to make sure
+mark does not get freed under us.
+
+Reported-by: Tony Jones <tonyj@suse.de>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Tested-by: Tony Jones <tonyj@suse.de>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/audit_watch.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/kernel/audit_watch.c
++++ b/kernel/audit_watch.c
+@@ -457,13 +457,15 @@ void audit_remove_watch_rule(struct audi
+ list_del(&krule->rlist);
+
+ if (list_empty(&watch->rules)) {
++ /*
++ * audit_remove_watch() drops our reference to 'parent' which
++ * can get freed. Grab our own reference to be safe.
++ */
++ audit_get_parent(parent);
+ audit_remove_watch(watch);
+-
+- if (list_empty(&parent->watches)) {
+- audit_get_parent(parent);
++ if (list_empty(&parent->watches))
+ fsnotify_destroy_mark(&parent->mark, audit_watch_group);
+- audit_put_parent(parent);
+- }
++ audit_put_parent(parent);
+ }
+ }
+
--- /dev/null
+From 28389575a8cf933a5f3c378556b9f4d3cce0efd2 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Wed, 2 Aug 2017 16:40:47 +0800
+Subject: crypto: ixp4xx - Fix error handling path in 'aead_perform()'
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit 28389575a8cf933a5f3c378556b9f4d3cce0efd2 upstream.
+
+In commit 0f987e25cb8a, the source processing has been moved in front of
+the destination processing, but the error handling path has not been
+modified accordingly.
+Free resources in the correct order to avoid some leaks.
+
+Fixes: 0f987e25cb8a ("crypto: ixp4xx - Fix false lastlen uninitialised warning")
+Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/ixp4xx_crypto.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/crypto/ixp4xx_crypto.c
++++ b/drivers/crypto/ixp4xx_crypto.c
+@@ -1074,7 +1074,7 @@ static int aead_perform(struct aead_requ
+ req_ctx->hmac_virt = dma_pool_alloc(buffer_pool, flags,
+ &crypt->icv_rev_aes);
+ if (unlikely(!req_ctx->hmac_virt))
+- goto free_buf_src;
++ goto free_buf_dst;
+ if (!encrypt) {
+ scatterwalk_map_and_copy(req_ctx->hmac_virt,
+ req->src, cryptlen, authsize, 0);
+@@ -1089,10 +1089,10 @@ static int aead_perform(struct aead_requ
+ BUG_ON(qmgr_stat_overflow(SEND_QID));
+ return -EINPROGRESS;
+
+-free_buf_src:
+- free_buf_chain(dev, req_ctx->src, crypt->src_buf);
+ free_buf_dst:
+ free_buf_chain(dev, req_ctx->dst, crypt->dst_buf);
++free_buf_src:
++ free_buf_chain(dev, req_ctx->src, crypt->src_buf);
+ crypt->ctl_flags = CTL_FLAG_UNUSED;
+ return -ENOMEM;
+ }
--- /dev/null
+From 8861249c740fc4af9ddc5aee321eafefb960d7c6 Mon Sep 17 00:00:00 2001
+From: "megha.dey@linux.intel.com" <megha.dey@linux.intel.com>
+Date: Wed, 2 Aug 2017 13:49:09 -0700
+Subject: crypto: x86/sha1 - Fix reads beyond the number of blocks passed
+
+From: megha.dey@linux.intel.com <megha.dey@linux.intel.com>
+
+commit 8861249c740fc4af9ddc5aee321eafefb960d7c6 upstream.
+
+It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
+reading ahead beyond its intended data, and causing a crash if the next
+block is beyond page boundary:
+http://marc.info/?l=linux-crypto-vger&m=149373371023377
+
+This patch makes sure that there is no overflow for any buffer length.
+
+It passes the tests written by Jan Stancek that revealed this problem:
+https://github.com/jstancek/sha1-avx2-crash
+
+I have re-enabled sha1-avx2 by reverting commit
+b82ce24426a4071da9529d726057e4e642948667
+
+Fixes: b82ce24426a4 ("crypto: sha1-ssse3 - Disable avx2")
+Originally-by: Ilya Albrekht <ilya.albrekht@intel.com>
+Tested-by: Jan Stancek <jstancek@redhat.com>
+Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
+Reported-by: Jan Stancek <jstancek@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/crypto/sha1_avx2_x86_64_asm.S | 67 +++++++++++++++++----------------
+ arch/x86/crypto/sha1_ssse3_glue.c | 2
+ 2 files changed, 37 insertions(+), 32 deletions(-)
+
+--- a/arch/x86/crypto/sha1_avx2_x86_64_asm.S
++++ b/arch/x86/crypto/sha1_avx2_x86_64_asm.S
+@@ -117,11 +117,10 @@
+ .set T1, REG_T1
+ .endm
+
+-#define K_BASE %r8
+ #define HASH_PTR %r9
++#define BLOCKS_CTR %r8
+ #define BUFFER_PTR %r10
+ #define BUFFER_PTR2 %r13
+-#define BUFFER_END %r11
+
+ #define PRECALC_BUF %r14
+ #define WK_BUF %r15
+@@ -205,14 +204,14 @@
+ * blended AVX2 and ALU instruction scheduling
+ * 1 vector iteration per 8 rounds
+ */
+- vmovdqu ((i * 2) + PRECALC_OFFSET)(BUFFER_PTR), W_TMP
++ vmovdqu (i * 2)(BUFFER_PTR), W_TMP
+ .elseif ((i & 7) == 1)
+- vinsertf128 $1, (((i-1) * 2)+PRECALC_OFFSET)(BUFFER_PTR2),\
++ vinsertf128 $1, ((i-1) * 2)(BUFFER_PTR2),\
+ WY_TMP, WY_TMP
+ .elseif ((i & 7) == 2)
+ vpshufb YMM_SHUFB_BSWAP, WY_TMP, WY
+ .elseif ((i & 7) == 4)
+- vpaddd K_XMM(K_BASE), WY, WY_TMP
++ vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP
+ .elseif ((i & 7) == 7)
+ vmovdqu WY_TMP, PRECALC_WK(i&~7)
+
+@@ -255,7 +254,7 @@
+ vpxor WY, WY_TMP, WY_TMP
+ .elseif ((i & 7) == 7)
+ vpxor WY_TMP2, WY_TMP, WY
+- vpaddd K_XMM(K_BASE), WY, WY_TMP
++ vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP
+ vmovdqu WY_TMP, PRECALC_WK(i&~7)
+
+ PRECALC_ROTATE_WY
+@@ -291,7 +290,7 @@
+ vpsrld $30, WY, WY
+ vpor WY, WY_TMP, WY
+ .elseif ((i & 7) == 7)
+- vpaddd K_XMM(K_BASE), WY, WY_TMP
++ vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP
+ vmovdqu WY_TMP, PRECALC_WK(i&~7)
+
+ PRECALC_ROTATE_WY
+@@ -446,6 +445,16 @@
+
+ .endm
+
++/* Add constant only if (%2 > %3) condition met (uses RTA as temp)
++ * %1 + %2 >= %3 ? %4 : 0
++ */
++.macro ADD_IF_GE a, b, c, d
++ mov \a, RTA
++ add $\d, RTA
++ cmp $\c, \b
++ cmovge RTA, \a
++.endm
++
+ /*
+ * macro implements 80 rounds of SHA-1, for multiple blocks with s/w pipelining
+ */
+@@ -463,13 +472,16 @@
+ lea (2*4*80+32)(%rsp), WK_BUF
+
+ # Precalc WK for first 2 blocks
+- PRECALC_OFFSET = 0
++ ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 2, 64
+ .set i, 0
+ .rept 160
+ PRECALC i
+ .set i, i + 1
+ .endr
+- PRECALC_OFFSET = 128
++
++ /* Go to next block if needed */
++ ADD_IF_GE BUFFER_PTR, BLOCKS_CTR, 3, 128
++ ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 4, 128
+ xchg WK_BUF, PRECALC_BUF
+
+ .align 32
+@@ -479,8 +491,8 @@ _loop:
+ * we use K_BASE value as a signal of a last block,
+ * it is set below by: cmovae BUFFER_PTR, K_BASE
+ */
+- cmp K_BASE, BUFFER_PTR
+- jne _begin
++ test BLOCKS_CTR, BLOCKS_CTR
++ jnz _begin
+ .align 32
+ jmp _end
+ .align 32
+@@ -512,10 +524,10 @@ _loop0:
+ .set j, j+2
+ .endr
+
+- add $(2*64), BUFFER_PTR /* move to next odd-64-byte block */
+- cmp BUFFER_END, BUFFER_PTR /* is current block the last one? */
+- cmovae K_BASE, BUFFER_PTR /* signal the last iteration smartly */
+-
++ /* Update Counter */
++ sub $1, BLOCKS_CTR
++ /* Move to the next block only if needed*/
++ ADD_IF_GE BUFFER_PTR, BLOCKS_CTR, 4, 128
+ /*
+ * rounds
+ * 60,62,64,66,68
+@@ -532,8 +544,8 @@ _loop0:
+ UPDATE_HASH 12(HASH_PTR), D
+ UPDATE_HASH 16(HASH_PTR), E
+
+- cmp K_BASE, BUFFER_PTR /* is current block the last one? */
+- je _loop
++ test BLOCKS_CTR, BLOCKS_CTR
++ jz _loop
+
+ mov TB, B
+
+@@ -575,10 +587,10 @@ _loop2:
+ .set j, j+2
+ .endr
+
+- add $(2*64), BUFFER_PTR2 /* move to next even-64-byte block */
+-
+- cmp BUFFER_END, BUFFER_PTR2 /* is current block the last one */
+- cmovae K_BASE, BUFFER_PTR /* signal the last iteration smartly */
++ /* update counter */
++ sub $1, BLOCKS_CTR
++ /* Move to the next block only if needed*/
++ ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 4, 128
+
+ jmp _loop3
+ _loop3:
+@@ -641,19 +653,12 @@ _loop3:
+
+ avx2_zeroupper
+
+- lea K_XMM_AR(%rip), K_BASE
+-
++ /* Setup initial values */
+ mov CTX, HASH_PTR
+ mov BUF, BUFFER_PTR
+- lea 64(BUF), BUFFER_PTR2
+-
+- shl $6, CNT /* mul by 64 */
+- add BUF, CNT
+- add $64, CNT
+- mov CNT, BUFFER_END
+
+- cmp BUFFER_END, BUFFER_PTR2
+- cmovae K_BASE, BUFFER_PTR2
++ mov BUF, BUFFER_PTR2
++ mov CNT, BLOCKS_CTR
+
+ xmm_mov BSWAP_SHUFB_CTL(%rip), YMM_SHUFB_BSWAP
+
+--- a/arch/x86/crypto/sha1_ssse3_glue.c
++++ b/arch/x86/crypto/sha1_ssse3_glue.c
+@@ -201,7 +201,7 @@ asmlinkage void sha1_transform_avx2(u32
+
+ static bool avx2_usable(void)
+ {
+- if (false && avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
++ if (avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
+ && boot_cpu_has(X86_FEATURE_BMI1)
+ && boot_cpu_has(X86_FEATURE_BMI2))
+ return true;
--- /dev/null
+From 7a7c286d07f9c704e8fd11dd960bf421cc67b66b Mon Sep 17 00:00:00 2001
+From: Chunming Zhou <David1.Zhou@amd.com>
+Date: Fri, 11 Aug 2017 09:34:33 +0800
+Subject: drm/amdgpu: save list length when fence is signaled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chunming Zhou <David1.Zhou@amd.com>
+
+commit 7a7c286d07f9c704e8fd11dd960bf421cc67b66b upstream.
+
+update the list first to avoid redundant checks.
+
+Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+@@ -244,6 +244,12 @@ struct dma_fence *amdgpu_sync_peek_fence
+ struct dma_fence *f = e->fence;
+ struct amd_sched_fence *s_fence = to_amd_sched_fence(f);
+
++ if (dma_fence_is_signaled(f)) {
++ hash_del(&e->node);
++ dma_fence_put(f);
++ kmem_cache_free(amdgpu_sync_slab, e);
++ continue;
++ }
+ if (ring && s_fence) {
+ /* For fences from the same ring it is sufficient
+ * when they are scheduled.
+@@ -256,13 +262,6 @@ struct dma_fence *amdgpu_sync_peek_fence
+ }
+ }
+
+- if (dma_fence_is_signaled(f)) {
+- hash_del(&e->node);
+- dma_fence_put(f);
+- kmem_cache_free(amdgpu_sync_slab, e);
+- continue;
+- }
+-
+ return f;
+ }
+
--- /dev/null
+From a0125a932e917cb507b682cb66645efdca1f8cab Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 8 Aug 2017 14:19:04 +0100
+Subject: drm/i915: Perform an invalidate prior to executing golden renderstate
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit a0125a932e917cb507b682cb66645efdca1f8cab upstream.
+
+As we may have just bound the renderstate into the GGTT for execution, we
+need to ensure that the GTT TLB are also flushed.
+
+On snb-gt2, this would cause a random GPU hang at the start of a new
+context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
+to take ~10s. It was the GPU hang that revealed the truth, as the CS
+gleefully executed beyond the end of the golden renderstate batch, a good
+indicator for a GTT TLB miss.
+
+Fixes: 20fe17aa52dc ("drm/i915: Remove redundant TLB invalidate on switching contexts")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20170808131904.1385-1-chris@chris-wilson.co.uk
+Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.12-rc1+
+(cherry picked from commit 802673d66f8a6ded5d2689d597853c7bb3a70163)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_render_state.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
++++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
+@@ -242,6 +242,10 @@ int i915_gem_render_state_emit(struct dr
+ goto err_unpin;
+ }
+
++ ret = req->engine->emit_flush(req, EMIT_INVALIDATE);
++ if (ret)
++ goto err_unpin;
++
+ ret = req->engine->emit_bb_start(req,
+ so->batch_offset, so->batch_size,
+ I915_DISPATCH_SECURE);
--- /dev/null
+From 76988690402dde2880bfe06ecccf381d48ba8e1c Mon Sep 17 00:00:00 2001
+From: KT Liao <kt.liao@emc.com.tw>
+Date: Mon, 14 Aug 2017 20:11:59 -0700
+Subject: Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
+
+From: KT Liao <kt.liao@emc.com.tw>
+
+commit 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.
+
+Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should
+be handled by the driver.
+
+Signed-off-by: KT Liao <kt.liao@emc.com.tw>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1225,6 +1225,9 @@ static const struct acpi_device_id elan_
+ { "ELAN0600", 0 },
+ { "ELAN0605", 0 },
+ { "ELAN0608", 0 },
++ { "ELAN0605", 0 },
++ { "ELAN0609", 0 },
++ { "ELAN060B", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From 1874064eed0502bd9bef7be8023757b0c4f26883 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Mon, 14 Aug 2017 20:11:26 -0700
+Subject: Input: elan_i2c - add ELAN0608 to the ACPI table
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 1874064eed0502bd9bef7be8023757b0c4f26883 upstream.
+
+Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
+ACPI table"), ELAN0608 should be handled by elan_i2c.
+
+This touchpad can be found in Lenovo ideapad 320-14IKB.
+
+BugLink: https://bugs.launchpad.net/bugs/1708852
+
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1224,6 +1224,7 @@ static const struct acpi_device_id elan_
+ { "ELAN0100", 0 },
+ { "ELAN0600", 0 },
+ { "ELAN0605", 0 },
++ { "ELAN0608", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From 33182d15c6bf182f7ae32a66ea4a547d979cd6d7 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Tue, 8 Aug 2017 16:56:36 +1000
+Subject: md: always clear ->safemode when md_check_recovery gets the mddev lock.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 33182d15c6bf182f7ae32a66ea4a547d979cd6d7 upstream.
+
+If ->safemode == 1, md_check_recovery() will try to get the mddev lock
+and perform various other checks.
+If mddev->in_sync is zero, it will call set_in_sync, and clear
+->safemode. However if mddev->in_sync is not zero, ->safemode will not
+be cleared.
+
+When md_check_recovery() drops the mddev lock, the thread is woken
+up again. Normally it would just check if there was anything else to
+do, find nothing, and go to sleep. However as ->safemode was not
+cleared, it will take the mddev lock again, then wake itself up
+when unlocking.
+
+This results in an infinite loop, repeatedly calling
+md_check_recovery(), which RCU or the soft-lockup detector
+will eventually complain about.
+
+Prior to commit 4ad23a976413 ("MD: use per-cpu counter for
+writes_pending"), safemode would only be set to one when the
+writes_pending counter reached zero, and would be cleared again
+when writes_pending is incremented. Since that patch, safemode
+is set more freely, but is not reliably cleared.
+
+So in md_check_recovery() clear ->safemode before checking ->in_sync.
+
+Fixes: 4ad23a976413 ("MD: use per-cpu counter for writes_pending")
+Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
+Reported-by: David R <david@unsolicited.net>
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -8639,6 +8639,9 @@ void md_check_recovery(struct mddev *mdd
+ if (mddev_trylock(mddev)) {
+ int spares = 0;
+
++ if (mddev->safemode == 1)
++ mddev->safemode = 0;
++
+ if (mddev->ro) {
+ struct md_rdev *rdev;
+ if (!mddev->external && mddev->in_sync)
--- /dev/null
+From 81fe48e9aa00bdd509bd3c37a76d1132da6b9f09 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Tue, 8 Aug 2017 16:56:36 +1000
+Subject: md: fix test in md_write_start()
+
+From: NeilBrown <neilb@suse.com>
+
+commit 81fe48e9aa00bdd509bd3c37a76d1132da6b9f09 upstream.
+
+md_write_start() needs to clear the in_sync flag is it is set, or if
+there might be a race with set_in_sync() such that the later will
+set it very soon. In the later case it is sufficient to take the
+spinlock to synchronize with set_in_sync(), and then set the flag
+if needed.
+
+The current test is incorrect.
+It should be:
+ if "flag is set" or "race is possible"
+
+"flag is set" is trivially "mddev->in_sync".
+"race is possible" should be tested by "mddev->sync_checkers".
+
+If sync_checkers is 0, then there can be no race. set_in_sync() will
+wait in percpu_ref_switch_to_atomic_sync() for an RCU grace period,
+and as md_write_start() holds the rcu_read_lock(), set_in_sync() will
+be sure ot see the update to writes_pending.
+
+If sync_checkers is > 0, there could be race. If md_write_start()
+happened entirely between
+ if (!mddev->in_sync &&
+ percpu_ref_is_zero(&mddev->writes_pending)) {
+and
+ mddev->in_sync = 1;
+in set_in_sync(), then it would not see that is_sync had been set,
+and set_in_sync() would not see that writes_pending had been
+incremented.
+
+This bug means that in_sync is sometimes not set when it should be.
+Consequently there is a small chance that the array will be marked as
+"clean" when in fact it is inconsistent.
+
+Fixes: 4ad23a976413 ("MD: use per-cpu counter for writes_pending")
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -7979,7 +7979,7 @@ bool md_write_start(struct mddev *mddev,
+ if (mddev->safemode == 1)
+ mddev->safemode = 0;
+ /* sync_checkers is always 0 when writes_pending is in per-cpu mode */
+- if (mddev->in_sync || !mddev->sync_checkers) {
++ if (mddev->in_sync || mddev->sync_checkers) {
+ spin_lock(&mddev->lock);
+ if (mddev->in_sync) {
+ mddev->in_sync = 0;
--- /dev/null
+From afc1f55ca44e257f69da8f43e0714a76686ae8d1 Mon Sep 17 00:00:00 2001
+From: Shaohua Li <shli@fb.com>
+Date: Fri, 11 Aug 2017 20:34:45 -0700
+Subject: MD: not clear ->safemode for external metadata array
+
+From: Shaohua Li <shli@fb.com>
+
+commit afc1f55ca44e257f69da8f43e0714a76686ae8d1 upstream.
+
+->safemode should be triggered by mdadm for external metadaa array, otherwise
+array's state confuses mdadm.
+
+Fixes: 33182d15c6bf(md: always clear ->safemode when md_check_recovery gets the mddev lock.)
+Cc: NeilBrown <neilb@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -8639,7 +8639,7 @@ void md_check_recovery(struct mddev *mdd
+ if (mddev_trylock(mddev)) {
+ int spares = 0;
+
+- if (mddev->safemode == 1)
++ if (!mddev->external && mddev->safemode == 1)
+ mddev->safemode = 0;
+
+ if (mddev->ro) {
--- /dev/null
+From 4098116039911e8870d84c975e2ec22dab65a909 Mon Sep 17 00:00:00 2001
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Date: Sat, 12 Aug 2017 23:36:47 +0200
+Subject: parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
+
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+commit 4098116039911e8870d84c975e2ec22dab65a909 upstream.
+
+For 64bit kernels the lmmio_space_offset of the host bridge window
+isn't set correctly on systems with dino/cujo PCI host bridges.
+This leads to not assigned memory bars and failing drivers, which
+need to use these bars.
+
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Acked-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/parisc/dino.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/parisc/dino.c
++++ b/drivers/parisc/dino.c
+@@ -956,7 +956,7 @@ static int __init dino_probe(struct pari
+
+ dino_dev->hba.dev = dev;
+ dino_dev->hba.base_addr = ioremap_nocache(hpa, 4096);
+- dino_dev->hba.lmmio_space_offset = 0; /* CPU addrs == bus addrs */
++ dino_dev->hba.lmmio_space_offset = PCI_F_EXTEND;
+ spin_lock_init(&dino_dev->dinosaur_pen);
+ dino_dev->hba.iommu = ccio_get_iommu(dev);
+
+audit-fix-use-after-free-in-audit_remove_watch_rule.patch
+parisc-pci-memory-bar-assignment-fails-with-64bit-kernels-on-dino-cujo.patch
+crypto-ixp4xx-fix-error-handling-path-in-aead_perform.patch
+crypto-x86-sha1-fix-reads-beyond-the-number-of-blocks-passed.patch
+drm-i915-perform-an-invalidate-prior-to-executing-golden-renderstate.patch
+drm-amdgpu-save-list-length-when-fence-is-signaled.patch
+input-elan_i2c-add-elan0608-to-the-acpi-table.patch
+input-elan_i2c-add-antoher-lenovo-acpi-id-for-upcoming-lenovo-nb.patch
+md-fix-test-in-md_write_start.patch
+md-always-clear-safemode-when-md_check_recovery-gets-the-mddev-lock.patch
+md-not-clear-safemode-for-external-metadata-array.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
