--- /dev/null
+From 41cdf7a45389e01991ee31e3301ed83cb3e3f7dc Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Mon, 17 Jul 2017 15:32:30 +0800
+Subject: crypto: authencesn - Fix digest_null crash
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit 41cdf7a45389e01991ee31e3301ed83cb3e3f7dc upstream.
+
+When authencesn is used together with digest_null a crash will
+occur on the decrypt path. This is because normally we perform
+a special setup to preserve the ESN, but this is skipped if there
+is no authentication. However, on the post-authentication path
+it always expects the preservation to be in place, thus causing
+a crash when digest_null is used.
+
+This patch fixes this by also skipping the post-processing when
+there is no authentication.
+
+Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD...")
+Reported-by: Jan Tluka <jtluka@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/authencesn.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/crypto/authencesn.c
++++ b/crypto/authencesn.c
+@@ -248,6 +248,9 @@ static int crypto_authenc_esn_decrypt_ta
+ u8 *ihash = ohash + crypto_ahash_digestsize(auth);
+ u32 tmp[2];
+
++ if (!authsize)
++ goto decrypt;
++
+ /* Move high-order bits of sequence number back. */
+ scatterwalk_map_and_copy(tmp, dst, 4, 4, 0);
+ scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 0);
+@@ -256,6 +259,8 @@ static int crypto_authenc_esn_decrypt_ta
+ if (crypto_memneq(ihash, ohash, authsize))
+ return -EBADMSG;
+
++decrypt:
++
+ sg_init_table(areq_ctx->dst, 2);
+ dst = scatterwalk_ffwd(areq_ctx->dst, dst, assoclen);
+
--- /dev/null
+From a7e6e5d8b221e57fed9fda6ec81153fda773c073 Mon Sep 17 00:00:00 2001
+From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
+Date: Fri, 23 Jun 2017 14:34:08 +0530
+Subject: crypto: brcm - Fix SHA3-512 algorithm failure
+
+From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
+
+commit a7e6e5d8b221e57fed9fda6ec81153fda773c073 upstream.
+
+In Broadcom SPU driver, due to missing break statement
+in spu2_hash_xlate() while mapping SPU2 equivalent
+SHA3-512 value, -EINVAL is chosen and hence leading to
+failure of SHA3-512 algorithm. This patch fixes the same.
+
+Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
+Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
+Reviewed-by: Ray Jui <ray.jui@broadcom.com>
+Reviewed-by: Scott Branden <scott.branden@broadcom.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/bcm/spu2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/crypto/bcm/spu2.c
++++ b/drivers/crypto/bcm/spu2.c
+@@ -302,6 +302,7 @@ spu2_hash_xlate(enum hash_alg hash_alg,
+ break;
+ case HASH_ALG_SHA3_512:
+ *spu2_type = SPU2_HASH_TYPE_SHA3_512;
++ break;
+ case HASH_ALG_LAST:
+ default:
+ err = -EINVAL;
--- /dev/null
+From efc856edfd66acc5da34fec92d7feca6fd0f9add Mon Sep 17 00:00:00 2001
+From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
+Date: Tue, 11 Jul 2017 15:50:06 +0530
+Subject: crypto: brcm - remove BCM_PDC_MBOX dependency in Kconfig
+
+From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
+
+commit efc856edfd66acc5da34fec92d7feca6fd0f9add upstream.
+
+SPU driver is dependent on generic MAILBOX API's to
+communicate with underlying DMA engine driver.
+
+So this patch removes BCM_PDC_MBOX "depends on" for SPU driver
+in Kconfig and adds MAILBOX as dependent module.
+
+Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
+Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
+Reviewed-by: Ray Jui <ray.jui@broadcom.com>
+Reviewed-by: Scott Branden <scott.branden@broadcom.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/Kconfig
++++ b/drivers/crypto/Kconfig
+@@ -629,7 +629,7 @@ source "drivers/crypto/virtio/Kconfig"
+ config CRYPTO_DEV_BCM_SPU
+ tristate "Broadcom symmetric crypto/hash acceleration support"
+ depends on ARCH_BCM_IPROC
+- depends on BCM_PDC_MBOX
++ depends on MAILBOX
+ default m
+ select CRYPTO_DES
+ select CRYPTO_MD5
--- /dev/null
+From 9dd59727dbc21d33a9add4c5b308a5775cd5a6ef Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 19 Jul 2017 11:23:40 -0400
+Subject: dm integrity: fix inefficient allocation of journal space
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 9dd59727dbc21d33a9add4c5b308a5775cd5a6ef upstream.
+
+When using a block size greater than 512 bytes, the dm-integrity target
+allocates journal space inefficiently. It allocates one journal entry
+for each 512-byte chunk of data, fills an entry for each block of data
+and leaves the remaining entries unused.
+
+This issue doesn't cause data corruption, but all the unused journal
+entries degrade performance severely.
+
+For example, with 4k blocks and an 8k bio, it would allocate 16 journal
+entries but only use 2 entries. The remaining 14 entries were left
+unused.
+
+Fix this by adding the missing 'log2_sectors_per_block' shifts that are
+required to have each journal entry map to a full block.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Fixes: 7eada909bfd7 ("dm: add integrity target")
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-integrity.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/dm-integrity.c
++++ b/drivers/md/dm-integrity.c
+@@ -1587,16 +1587,18 @@ retry:
+ if (likely(ic->mode == 'J')) {
+ if (dio->write) {
+ unsigned next_entry, i, pos;
+- unsigned ws, we;
++ unsigned ws, we, range_sectors;
+
+- dio->range.n_sectors = min(dio->range.n_sectors, ic->free_sectors);
++ dio->range.n_sectors = min(dio->range.n_sectors,
++ ic->free_sectors << ic->sb->log2_sectors_per_block);
+ if (unlikely(!dio->range.n_sectors))
+ goto sleep;
+- ic->free_sectors -= dio->range.n_sectors;
++ range_sectors = dio->range.n_sectors >> ic->sb->log2_sectors_per_block;
++ ic->free_sectors -= range_sectors;
+ journal_section = ic->free_section;
+ journal_entry = ic->free_section_entry;
+
+- next_entry = ic->free_section_entry + dio->range.n_sectors;
++ next_entry = ic->free_section_entry + range_sectors;
+ ic->free_section_entry = next_entry % ic->journal_section_entries;
+ ic->free_section += next_entry / ic->journal_section_entries;
+ ic->n_uncommitted_sections += next_entry / ic->journal_section_entries;
--- /dev/null
+From bc86a41e96c5b6f07453c405e036d95acc673389 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Fri, 21 Jul 2017 11:58:38 -0400
+Subject: dm integrity: test for corrupted disk format during table load
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit bc86a41e96c5b6f07453c405e036d95acc673389 upstream.
+
+If the dm-integrity superblock was corrupted in such a way that the
+journal_sections field was zero, the integrity target would deadlock
+because it would wait forever for free space in the journal.
+
+Detect this situation and refuse to activate the device.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Fixes: 7eada909bfd7 ("dm: add integrity target")
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-integrity.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/md/dm-integrity.c
++++ b/drivers/md/dm-integrity.c
+@@ -3021,6 +3021,11 @@ static int dm_integrity_ctr(struct dm_ta
+ ti->error = "Block size doesn't match the information in superblock";
+ goto bad;
+ }
++ if (!le32_to_cpu(ic->sb->journal_sections)) {
++ r = -EINVAL;
++ ti->error = "Corrupted superblock, journal_sections is 0";
++ goto bad;
++ }
+ /* make sure that ti->max_io_len doesn't overflow */
+ if (ic->sb->log2_interleave_sectors < MIN_LOG2_INTERLEAVE_SECTORS ||
+ ic->sb->log2_interleave_sectors > MAX_LOG2_INTERLEAVE_SECTORS) {
--- /dev/null
+From 283d6860d64f5091565bf729b0a6d6af14ae6c27 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Thu, 20 Jul 2017 14:28:20 +0300
+Subject: drm/i915: Fix scaler init during CRTC HW state readout
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 283d6860d64f5091565bf729b0a6d6af14ae6c27 upstream.
+
+The scaler allocation code depends on a non-zero default value for the
+crtc scaler_id, so make sure we initialize the scaler state accordingly
+even if the crtc is off. This fixes at least an initial YUV420 modeset
+(added in a follow-up patchset by Shashank) when booting with the screen
+off: after the initial HW readout and modeset which enables the scaler a
+subsequent modeset will disable the scaler which isn't properly
+allocated. This results in a funky HW state where the pipe scaler HW
+registers can't be modified and the normally black screen is grey and
+shifted to the right or jitters.
+
+The problem was revealed by Shashank's YUV420 patchset and first
+reported by Ville.
+
+v2:
+- In the stable tag also include versions which need backporting (Jani)
+
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: Shashank Sharma <shashank.sharma@intel.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Chandra Konduru <chandra.konduru@intel.com>
+Cc: Matt Roper <matthew.d.roper@intel.com>
+Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+(cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2)
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -9085,6 +9085,13 @@ static bool haswell_get_pipe_config(stru
+ u64 power_domain_mask;
+ bool active;
+
++ if (INTEL_GEN(dev_priv) >= 9) {
++ intel_crtc_init_scalers(crtc, pipe_config);
++
++ pipe_config->scaler_state.scaler_id = -1;
++ pipe_config->scaler_state.scaler_users &= ~(1 << SKL_CRTC_INDEX);
++ }
++
+ power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
+ if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
+ return false;
+@@ -9113,13 +9120,6 @@ static bool haswell_get_pipe_config(stru
+ pipe_config->gamma_mode =
+ I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
+
+- if (INTEL_GEN(dev_priv) >= 9) {
+- intel_crtc_init_scalers(crtc, pipe_config);
+-
+- pipe_config->scaler_state.scaler_id = -1;
+- pipe_config->scaler_state.scaler_users &= ~(1 << SKL_CRTC_INDEX);
+- }
+-
+ power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
+ if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
+ power_domain_mask |= BIT_ULL(power_domain);
--- /dev/null
+From 38bcb208f60924a031b9f809f7cd252ea4a94e5f Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Tue, 25 Jul 2017 11:06:47 +1000
+Subject: drm/nouveau/bar/gf100: fix access to upper half of BAR2
+
+From: Ben Skeggs <bskeggs@redhat.com>
+
+commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.
+
+Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
+mapped over the end of VRAM, even when the rest of the BAR has been set
+to virtual mode.
+
+We inherited our initial value from RM, but I'm not aware of any reason
+we need to keep it that way.
+
+This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
+
+Shout-out to NVIDIA for the quick response with the potential cause!
+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
+@@ -129,7 +129,7 @@ gf100_bar_init(struct nvkm_bar *base)
+
+ if (bar->bar[0].mem) {
+ addr = nvkm_memory_addr(bar->bar[0].mem) >> 12;
+- nvkm_wr32(device, 0x001714, 0xc0000000 | addr);
++ nvkm_wr32(device, 0x001714, 0x80000000 | addr);
+ }
+
+ return 0;
--- /dev/null
+From a90e049cacd965dade4dae7263b4d3fd550e78b6 Mon Sep 17 00:00:00 2001
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+Date: Wed, 28 Jun 2017 08:24:45 -0400
+Subject: drm/nouveau/disp/nv50-: bump max chans to 21
+
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+
+commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.
+
+GP102's cursors go from chan 17..20. Increase the array size to hold
+their data properly.
+
+Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
+Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h
++++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h
+@@ -27,7 +27,7 @@ struct nv50_disp {
+ u8 type[3];
+ } pior;
+
+- struct nv50_disp_chan *chan[17];
++ struct nv50_disp_chan *chan[21];
+ };
+
+ int nv50_disp_root_scanoutpos(NV50_DISP_MTHD_V0);
--- /dev/null
+From fcfffdd8f98ac305285dca568b5065ef86be6458 Mon Sep 17 00:00:00 2001
+From: Sinclair Yeh <syeh@vmware.com>
+Date: Mon, 17 Jul 2017 23:28:36 -0700
+Subject: drm/vmwgfx: Fix gcc-7.1.1 warning
+
+From: Sinclair Yeh <syeh@vmware.com>
+
+commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream.
+
+The current code does not look correct, and the reason for it is
+probably lost. Since this now generates a compiler warning,
+fix it to what makes sense.
+
+Reported-by: Arnd Bergmann <arnd@arndb.de>
+Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sinclair Yeh <syeh@vmware.com>
+Reviewed-by: Brian Paul <brianp@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+@@ -519,7 +519,7 @@ static int vmw_cmd_invalid(struct vmw_pr
+ struct vmw_sw_context *sw_context,
+ SVGA3dCmdHeader *header)
+ {
+- return capable(CAP_SYS_ADMIN) ? : -EINVAL;
++ return -EINVAL;
+ }
+
+ static int vmw_cmd_ok(struct vmw_private *dev_priv,
--- /dev/null
+From 7b009e76797c82178d7a03ae0eaad5951d975277 Mon Sep 17 00:00:00 2001
+From: Sinclair Yeh <syeh@vmware.com>
+Date: Mon, 17 Jul 2017 07:49:22 -0700
+Subject: drm/vmwgfx: Limit max desktop dimensions to 8Kx8K
+
+From: Sinclair Yeh <syeh@vmware.com>
+
+commit 7b009e76797c82178d7a03ae0eaad5951d975277 upstream.
+
+This was originally chosen to be an arbitrarily large number. However,
+some user mode may actually try to set a 16Kx16K mode and run into other
+issues.
+
+Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will
+just use this limit for now.
+
+Signed-off-by: Sinclair Yeh <syeh@vmware.com>
+Reviewed-by: Brian Paul <brianp@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+@@ -1640,8 +1640,8 @@ int vmw_kms_stdu_init_display(struct vmw
+ * something arbitrarily large and we will reject any layout
+ * that doesn't fit prim_bb_mem later
+ */
+- dev->mode_config.max_width = 16384;
+- dev->mode_config.max_height = 16384;
++ dev->mode_config.max_width = 8192;
++ dev->mode_config.max_height = 8192;
+ }
+
+ vmw_kms_create_implicit_placement_property(dev_priv, false);
--- /dev/null
+From e47057151422a67ce08747176fa21cb3b526a2c9 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Fri, 21 Jul 2017 13:57:14 +1000
+Subject: KVM: PPC: Book3S HV: Enable TM before accessing TM registers
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit e47057151422a67ce08747176fa21cb3b526a2c9 upstream.
+
+Commit 46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state
+properly", 2017-06-15) added code to read transactional memory (TM)
+registers but forgot to enable TM before doing so. The result is
+that if userspace does have live values in the TM registers, a KVM_RUN
+ioctl will cause a host kernel crash like this:
+
+[ 181.328511] Unrecoverable TM Unavailable Exception f60 at d00000001e7d9980
+[ 181.328605] Oops: Unrecoverable TM Unavailable Exception, sig: 6 [#1]
+[ 181.328613] SMP NR_CPUS=2048
+[ 181.328613] NUMA
+[ 181.328618] PowerNV
+[ 181.328646] Modules linked in: vhost_net vhost tap nfs_layout_nfsv41_files rpcsec_gss_krb5 nfsv4 dns_resolver nfs
++fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
++nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun ebtable_filter ebtables
++ip6table_filter ip6_tables iptable_filter bridge stp llc kvm_hv kvm nfsd ses enclosure scsi_transport_sas ghash_generic
++auth_rpcgss gf128mul xts sg ctr nfs_acl lockd vmx_crypto shpchp ipmi_powernv i2c_opal grace ipmi_devintf i2c_core
++powernv_rng sunrpc ipmi_msghandler ibmpowernv uio_pdrv_genirq uio leds_powernv powernv_op_panel ip_tables xfs sd_mod
++lpfc ipr bnx2x libata mdio ptp pps_core scsi_transport_fc libcrc32c dm_mirror dm_region_hash dm_log dm_mod
+[ 181.329278] CPU: 40 PID: 9926 Comm: CPU 0/KVM Not tainted 4.12.0+ #1
+[ 181.329337] task: c000003fc6980000 task.stack: c000003fe4d80000
+[ 181.329396] NIP: d00000001e7d9980 LR: d00000001e77381c CTR: d00000001e7d98f0
+[ 181.329465] REGS: c000003fe4d837e0 TRAP: 0f60 Not tainted (4.12.0+)
+[ 181.329523] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
+[ 181.329527] CR: 24022448 XER: 00000000
+[ 181.329608] CFAR: d00000001e773818 SOFTE: 1
+[ 181.329608] GPR00: d00000001e77381c c000003fe4d83a60 d00000001e7ef410 c000003fdcfe0000
+[ 181.329608] GPR04: c000003fe4f00000 0000000000000000 0000000000000000 c000003fd7954800
+[ 181.329608] GPR08: 0000000000000001 c000003fc6980000 0000000000000000 d00000001e7e2880
+[ 181.329608] GPR12: d00000001e7d98f0 c000000007b19000 00000001295220e0 00007fffc0ce2090
+[ 181.329608] GPR16: 0000010011886608 00007fff8c89f260 0000000000000001 00007fff8c080028
+[ 181.329608] GPR20: 0000000000000000 00000100118500a6 0000010011850000 0000010011850000
+[ 181.329608] GPR24: 00007fffc0ce1b48 0000010011850000 00000000d673b901 0000000000000000
+[ 181.329608] GPR28: 0000000000000000 c000003fdcfe0000 c000003fdcfe0000 c000003fe4f00000
+[ 181.330199] NIP [d00000001e7d9980] kvmppc_vcpu_run_hv+0x90/0x6b0 [kvm_hv]
+[ 181.330264] LR [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
+[ 181.330322] Call Trace:
+[ 181.330351] [c000003fe4d83a60] [d00000001e773478] kvmppc_set_one_reg+0x48/0x340 [kvm] (unreliable)
+[ 181.330437] [c000003fe4d83b30] [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
+[ 181.330513] [c000003fe4d83b50] [d00000001e7700b4] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
+[ 181.330586] [c000003fe4d83bd0] [d00000001e7642f8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
+[ 181.330658] [c000003fe4d83d40] [c0000000003451b8] do_vfs_ioctl+0xc8/0x8b0
+[ 181.330717] [c000003fe4d83de0] [c000000000345a64] SyS_ioctl+0xc4/0x120
+[ 181.330776] [c000003fe4d83e30] [c00000000000b004] system_call+0x58/0x6c
+[ 181.330833] Instruction dump:
+[ 181.330869] e92d0260 e9290b50 e9290108 792807e3 41820058 e92d0260 e9290b50 e9290108
+[ 181.330941] 792ae8a4 794a1f87 408204f4 e92d0260 <7d4022a6> f9490ff0 e92d0260 7d4122a6
+[ 181.331013] ---[ end trace 6f6ddeb4bfe92a92 ]---
+
+The fix is just to turn on the TM bit in the MSR before accessing the
+registers.
+
+Fixes: 46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
+Reported-by: Jan Stancek <jstancek@redhat.com>
+Tested-by: Jan Stancek <jstancek@redhat.com>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_hv.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/kvm/book3s_hv.c
++++ b/arch/powerpc/kvm/book3s_hv.c
+@@ -2938,6 +2938,8 @@ static int kvmppc_vcpu_run_hv(struct kvm
+ run->fail_entry.hardware_entry_failure_reason = 0;
+ return -EINVAL;
+ }
++ /* Enable TM so we can read the TM SPRs */
++ mtmsr(mfmsr() | MSR_TM);
+ current->thread.tm_tfhar = mfspr(SPRN_TFHAR);
+ current->thread.tm_tfiar = mfspr(SPRN_TFIAR);
+ current->thread.tm_texasr = mfspr(SPRN_TEXASR);
--- /dev/null
+From ef42719814db06fdfa26cd7566de0b64de173320 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Fri, 21 Jul 2017 15:41:49 +1000
+Subject: KVM: PPC: Book3S HV: Fix host crash on changing HPT size
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit ef42719814db06fdfa26cd7566de0b64de173320 upstream.
+
+Commit f98a8bf9ee20 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB
+ioctl() to change HPT size", 2016-12-20) changed the behaviour of
+the KVM_PPC_ALLOCATE_HTAB ioctl so that it now allocates a new HPT
+and new revmap array if there was a previously-allocated HPT of a
+different size from the size being requested. In this case, we need
+to reset the rmap arrays of the memslots, because the rmap arrays
+will contain references to HPTEs which are no longer valid. Worse,
+these references are also references to slots in the new revmap
+array (which parallels the HPT), and the new revmap array contains
+random contents, since it doesn't get zeroed on allocation.
+
+The effect of having these stale references to slots in the revmap
+array that contain random contents is that subsequent calls to
+functions such as kvmppc_add_revmap_chain will crash because they
+will interpret the non-zero contents of the revmap array as HPTE
+indexes and thus index outside of the revmap array. This leads to
+host crashes such as the following.
+
+[ 7072.862122] Unable to handle kernel paging request for data at address 0xd000000c250c00f8
+[ 7072.862218] Faulting instruction address: 0xc0000000000e1c78
+[ 7072.862233] Oops: Kernel access of bad area, sig: 11 [#1]
+[ 7072.862286] SMP NR_CPUS=1024
+[ 7072.862286] NUMA
+[ 7072.862325] PowerNV
+[ 7072.862378] Modules linked in: kvm_hv vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm iw_cxgb3 mlx5_ib ib_core ses enclosure scsi_transport_sas ipmi_powernv ipmi_devintf ipmi_msghandler powernv_op_panel i2c_opal nfsd auth_rpcgss oid_registry
+[ 7072.863085] nfs_acl lockd grace sunrpc kvm_pr kvm xfs libcrc32c scsi_dh_alua dm_service_time radeon lpfc nvme_fc nvme_fabrics nvme_core scsi_transport_fc i2c_algo_bit tg3 drm_kms_helper ptp pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm dm_multipath i2c_core cxgb3 mlx5_core mdio [last unloaded: kvm_hv]
+[ 7072.863381] CPU: 72 PID: 56929 Comm: qemu-system-ppc Not tainted 4.12.0-kvm+ #59
+[ 7072.863457] task: c000000fe29e7600 task.stack: c000001e3ffec000
+[ 7072.863520] NIP: c0000000000e1c78 LR: c0000000000e2e3c CTR: c0000000000e25f0
+[ 7072.863596] REGS: c000001e3ffef560 TRAP: 0300 Not tainted (4.12.0-kvm+)
+[ 7072.863658] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE,TM[E]>
+[ 7072.863667] CR: 44082882 XER: 20000000
+[ 7072.863767] CFAR: c0000000000e2e38 DAR: d000000c250c00f8 DSISR: 42000000 SOFTE: 1
+GPR00: c0000000000e2e3c c000001e3ffef7e0 c000000001407d00 d000000c250c00f0
+GPR04: d00000006509fb70 d00000000b3d2048 0000000003ffdfb7 0000000000000000
+GPR08: 00000001007fdfb7 00000000c000000f d0000000250c0000 000000000070f7bf
+GPR12: 0000000000000008 c00000000fdad000 0000000010879478 00000000105a0d78
+GPR16: 00007ffaf4080000 0000000000001190 0000000000000000 0000000000010000
+GPR20: 4001ffffff000415 d00000006509fb70 0000000004091190 0000000ee1881190
+GPR24: 0000000003ffdfb7 0000000003ffdfb7 00000000007fdfb7 c000000f5c958000
+GPR28: d00000002d09fb70 0000000003ffdfb7 d00000006509fb70 d00000000b3d2048
+[ 7072.864439] NIP [c0000000000e1c78] kvmppc_add_revmap_chain+0x88/0x130
+[ 7072.864503] LR [c0000000000e2e3c] kvmppc_do_h_enter+0x84c/0x9e0
+[ 7072.864566] Call Trace:
+[ 7072.864594] [c000001e3ffef7e0] [c000001e3ffef830] 0xc000001e3ffef830 (unreliable)
+[ 7072.864671] [c000001e3ffef830] [c0000000000e2e3c] kvmppc_do_h_enter+0x84c/0x9e0
+[ 7072.864751] [c000001e3ffef920] [d00000000b38d878] kvmppc_map_vrma+0x168/0x200 [kvm_hv]
+[ 7072.864831] [c000001e3ffef9e0] [d00000000b38a684] kvmppc_vcpu_run_hv+0x1284/0x1300 [kvm_hv]
+[ 7072.864914] [c000001e3ffefb30] [d00000000f465664] kvmppc_vcpu_run+0x44/0x60 [kvm]
+[ 7072.865008] [c000001e3ffefb60] [d00000000f461864] kvm_arch_vcpu_ioctl_run+0x114/0x290 [kvm]
+[ 7072.865152] [c000001e3ffefbe0] [d00000000f453c98] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
+[ 7072.865292] [c000001e3ffefd40] [c000000000389328] do_vfs_ioctl+0xd8/0x8c0
+[ 7072.865410] [c000001e3ffefde0] [c000000000389be4] SyS_ioctl+0xd4/0x130
+[ 7072.865526] [c000001e3ffefe30] [c00000000000b760] system_call+0x58/0x6c
+[ 7072.865644] Instruction dump:
+[ 7072.865715] e95b2110 793a0020 7b4926e4 7f8a4a14 409e0098 807c000c 786326e4 7c6a1a14
+[ 7072.865857] 935e0008 7bbd0020 813c000c 913e000c <93a30008> 93bc000c 48000038 60000000
+[ 7072.866001] ---[ end trace 627b6e4bf8080edc ]---
+
+Note that to trigger this, it is necessary to use a recent upstream
+QEMU (or other userspace that resizes the HPT at CAS time), specify
+a maximum memory size substantially larger than the current memory
+size, and boot a guest kernel that does not support HPT resizing.
+
+This fixes the problem by resetting the rmap arrays when the old HPT
+is freed.
+
+Fixes: f98a8bf9ee20 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size")
+Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
++++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
+@@ -164,8 +164,10 @@ long kvmppc_alloc_reset_hpt(struct kvm *
+ goto out;
+ }
+
+- if (kvm->arch.hpt.virt)
++ if (kvm->arch.hpt.virt) {
+ kvmppc_free_hpt(&kvm->arch.hpt);
++ kvmppc_rmap_reset(kvm);
++ }
+
+ err = kvmppc_allocate_hpt(&info, order);
+ if (err < 0)
--- /dev/null
+From 16d56e2fcc1fc15b981369653c3b41d7ff0b443d Mon Sep 17 00:00:00 2001
+From: Shaohua Li <shli@fb.com>
+Date: Mon, 17 Jul 2017 14:33:48 -0700
+Subject: md/raid1: fix writebehind bio clone
+
+From: Shaohua Li <shli@fb.com>
+
+commit 16d56e2fcc1fc15b981369653c3b41d7ff0b443d upstream.
+
+After bio is submitted, we should not clone it as its bi_iter might be
+invalid by driver. This is the case of behind_master_bio. In certain
+situration, we could dispatch behind_master_bio immediately for the
+first disk and then clone it for other disks.
+
+https://bugzilla.kernel.org/show_bug.cgi?id=196383
+
+Reported-and-tested-by: Markus <m4rkusxxl@web.de>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Fix: 841c1316c7da(md: raid1: improve write behind)
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid1.c | 34 +++++++++++++---------------------
+ 1 file changed, 13 insertions(+), 21 deletions(-)
+
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -491,10 +491,6 @@ static void raid1_end_write_request(stru
+ }
+
+ if (behind) {
+- /* we release behind master bio when all write are done */
+- if (r1_bio->behind_master_bio == bio)
+- to_put = NULL;
+-
+ if (test_bit(WriteMostly, &rdev->flags))
+ atomic_dec(&r1_bio->behind_remaining);
+
+@@ -1087,7 +1083,7 @@ static void unfreeze_array(struct r1conf
+ wake_up(&conf->wait_barrier);
+ }
+
+-static struct bio *alloc_behind_master_bio(struct r1bio *r1_bio,
++static void alloc_behind_master_bio(struct r1bio *r1_bio,
+ struct bio *bio)
+ {
+ int size = bio->bi_iter.bi_size;
+@@ -1097,11 +1093,13 @@ static struct bio *alloc_behind_master_b
+
+ behind_bio = bio_alloc_mddev(GFP_NOIO, vcnt, r1_bio->mddev);
+ if (!behind_bio)
+- goto fail;
++ return;
+
+ /* discard op, we don't support writezero/writesame yet */
+- if (!bio_has_data(bio))
++ if (!bio_has_data(bio)) {
++ behind_bio->bi_iter.bi_size = size;
+ goto skip_copy;
++ }
+
+ while (i < vcnt && size) {
+ struct page *page;
+@@ -1122,14 +1120,13 @@ skip_copy:
+ r1_bio->behind_master_bio = behind_bio;;
+ set_bit(R1BIO_BehindIO, &r1_bio->state);
+
+- return behind_bio;
++ return;
+
+ free_pages:
+ pr_debug("%dB behind alloc failed, doing sync I/O\n",
+ bio->bi_iter.bi_size);
+ bio_free_pages(behind_bio);
+-fail:
+- return behind_bio;
++ bio_put(behind_bio);
+ }
+
+ struct raid1_plug_cb {
+@@ -1482,7 +1479,7 @@ static void raid1_write_request(struct m
+ (atomic_read(&bitmap->behind_writes)
+ < mddev->bitmap_info.max_write_behind) &&
+ !waitqueue_active(&bitmap->behind_wait)) {
+- mbio = alloc_behind_master_bio(r1_bio, bio);
++ alloc_behind_master_bio(r1_bio, bio);
+ }
+
+ bitmap_startwrite(bitmap, r1_bio->sector,
+@@ -1492,14 +1489,11 @@ static void raid1_write_request(struct m
+ first_clone = 0;
+ }
+
+- if (!mbio) {
+- if (r1_bio->behind_master_bio)
+- mbio = bio_clone_fast(r1_bio->behind_master_bio,
+- GFP_NOIO,
+- mddev->bio_set);
+- else
+- mbio = bio_clone_fast(bio, GFP_NOIO, mddev->bio_set);
+- }
++ if (r1_bio->behind_master_bio)
++ mbio = bio_clone_fast(r1_bio->behind_master_bio,
++ GFP_NOIO, mddev->bio_set);
++ else
++ mbio = bio_clone_fast(bio, GFP_NOIO, mddev->bio_set);
+
+ if (r1_bio->behind_master_bio) {
+ if (test_bit(WriteMostly, &conf->mirrors[i].rdev->flags))
+@@ -2367,8 +2361,6 @@ static int narrow_write_error(struct r1b
+ wbio = bio_clone_fast(r1_bio->behind_master_bio,
+ GFP_NOIO,
+ mddev->bio_set);
+- /* We really need a _all clone */
+- wbio->bi_iter = (struct bvec_iter){ 0 };
+ } else {
+ wbio = bio_clone_fast(r1_bio->master_bio, GFP_NOIO,
+ mddev->bio_set);
--- /dev/null
+From 7e96d559634b73a8158ee99a7abece2eacec2668 Mon Sep 17 00:00:00 2001
+From: Ofer Heifetz <oferh@marvell.com>
+Date: Mon, 24 Jul 2017 09:17:40 +0300
+Subject: md/raid5: add thread_group worker async_tx_issue_pending_all
+
+From: Ofer Heifetz <oferh@marvell.com>
+
+commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream.
+
+Since thread_group worker and raid5d kthread are not in sync, if
+worker writes stripe before raid5d then requests will be waiting
+for issue_pendig.
+
+Issue observed when building raid5 with ext4, in some build runs
+jbd2 would get hung and requests were waiting in the HW engine
+waiting to be issued.
+
+Fix this by adding a call to async_tx_issue_pending_all in the
+raid5_do_work.
+
+Signed-off-by: Ofer Heifetz <oferh@marvell.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -6237,6 +6237,8 @@ static void raid5_do_work(struct work_st
+ pr_debug("%d stripes handled\n", handled);
+
+ spin_unlock_irq(&conf->device_lock);
++
++ async_tx_issue_pending_all();
+ blk_finish_plug(&plug);
+
+ pr_debug("--- raid5worker inactive\n");
--- /dev/null
+From 022e510fcbda79183fd2cdc01abb01b4be80d03f Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Fri, 14 Jul 2017 16:14:42 +0800
+Subject: md: remove 'idx' from 'struct resync_pages'
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit 022e510fcbda79183fd2cdc01abb01b4be80d03f upstream.
+
+bio_add_page() won't fail for resync bio, and the page index for each
+bio is same, so remove it.
+
+More importantly the 'idx' of 'struct resync_pages' is initialized in
+mempool allocator function, the current way is wrong since mempool is
+only responsible for allocation, we can't use that for initialization.
+
+Suggested-by: NeilBrown <neilb@suse.com>
+Reported-by: NeilBrown <neilb@suse.com>
+Reported-and-tested-by: Patrick <dto@gmx.net>
+Fixes: f0250618361d(md: raid10: don't use bio's vec table to manage resync pages)
+Fixes: 98d30c5812c3(md: raid1: don't use bio's vec table to manage resync pages)
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.h | 1 -
+ drivers/md/raid1.c | 6 +++---
+ drivers/md/raid10.c | 6 +++---
+ 3 files changed, 6 insertions(+), 7 deletions(-)
+
+--- a/drivers/md/md.h
++++ b/drivers/md/md.h
+@@ -733,7 +733,6 @@ static inline void mddev_check_write_zer
+
+ /* for managing resync I/O pages */
+ struct resync_pages {
+- unsigned idx; /* for get/put page from the pool */
+ void *raid_bio;
+ struct page *pages[RESYNC_PAGES];
+ };
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -170,7 +170,6 @@ static void * r1buf_pool_alloc(gfp_t gfp
+ resync_get_all_pages(rp);
+ }
+
+- rp->idx = 0;
+ rp->raid_bio = r1_bio;
+ bio->bi_private = rp;
+ }
+@@ -2621,6 +2620,7 @@ static sector_t raid1_sync_request(struc
+ int good_sectors = RESYNC_SECTORS;
+ int min_bad = 0; /* number of sectors that are bad in all devices */
+ int idx = sector_to_idx(sector_nr);
++ int page_idx = 0;
+
+ if (!conf->r1buf_pool)
+ if (init_resync(conf))
+@@ -2848,7 +2848,7 @@ static sector_t raid1_sync_request(struc
+ bio = r1_bio->bios[i];
+ rp = get_resync_pages(bio);
+ if (bio->bi_end_io) {
+- page = resync_fetch_page(rp, rp->idx++);
++ page = resync_fetch_page(rp, page_idx);
+
+ /*
+ * won't fail because the vec table is big
+@@ -2860,7 +2860,7 @@ static sector_t raid1_sync_request(struc
+ nr_sectors += len>>9;
+ sector_nr += len>>9;
+ sync_blocks -= (len>>9);
+- } while (get_resync_pages(r1_bio->bios[disk]->bi_private)->idx < RESYNC_PAGES);
++ } while (++page_idx < RESYNC_PAGES);
+
+ r1_bio->sectors = nr_sectors;
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -221,7 +221,6 @@ static void * r10buf_pool_alloc(gfp_t gf
+ resync_get_all_pages(rp);
+ }
+
+- rp->idx = 0;
+ rp->raid_bio = r10_bio;
+ bio->bi_private = rp;
+ if (rbio) {
+@@ -2853,6 +2852,7 @@ static sector_t raid10_sync_request(stru
+ sector_t sectors_skipped = 0;
+ int chunks_skipped = 0;
+ sector_t chunk_mask = conf->geo.chunk_mask;
++ int page_idx = 0;
+
+ if (!conf->r10buf_pool)
+ if (init_resync(conf))
+@@ -3355,7 +3355,7 @@ static sector_t raid10_sync_request(stru
+ break;
+ for (bio= biolist ; bio ; bio=bio->bi_next) {
+ struct resync_pages *rp = get_resync_pages(bio);
+- page = resync_fetch_page(rp, rp->idx++);
++ page = resync_fetch_page(rp, page_idx);
+ /*
+ * won't fail because the vec table is big enough
+ * to hold all these pages
+@@ -3364,7 +3364,7 @@ static sector_t raid10_sync_request(stru
+ }
+ nr_sectors += len>>9;
+ sector_nr += len>>9;
+- } while (get_resync_pages(biolist)->idx < RESYNC_PAGES);
++ } while (++page_idx < RESYNC_PAGES);
+ r10_bio->sectors = nr_sectors;
+
+ while (biolist) {
--- /dev/null
+From 26cb2be4c7c42644ccd147c786edb9006300ee56 Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Fri, 14 Jul 2017 14:42:55 +0800
+Subject: mmc: sunxi: Keep default timing phase settings for new timing mode
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit 26cb2be4c7c42644ccd147c786edb9006300ee56 upstream.
+
+The register for the "new timing mode" also has bit fields for setting
+output and sample timing phases. According to comments in Allwinner's
+BSP kernel, the default values are good enough.
+
+Keep the default values already in the hardware when setting new timing
+mode, instead of overwriting the whole register.
+
+Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
+controllers")
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sunxi-mmc.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sunxi-mmc.c
++++ b/drivers/mmc/host/sunxi-mmc.c
+@@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct
+ }
+ mmc_writel(host, REG_CLKCR, rval);
+
+- if (host->cfg->needs_new_timings)
+- mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
++ if (host->cfg->needs_new_timings) {
++ /* Don't touch the delay bits */
++ rval = mmc_readl(host, REG_SD_NTSR);
++ rval |= SDXC_2X_TIMING_MODE;
++ mmc_writel(host, REG_SD_NTSR, rval);
++ }
+
+ ret = sunxi_mmc_clk_set_phase(host, ios, rate);
+ if (ret)
--- /dev/null
+From 442ce0499c0535f8972b68fa1fda357357a5c953 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Mon, 24 Jul 2017 13:18:50 +1000
+Subject: NFS: invalidate file size when taking a lock.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 442ce0499c0535f8972b68fa1fda357357a5c953 upstream.
+
+Prior to commit ca0daa277aca ("NFS: Cache aggressively when file is open
+for writing"), NFS would revalidate, or invalidate, the file size when
+taking a lock. Since that commit it only invalidates the file content.
+
+If the file size is changed on the server while wait for the lock, the
+client will have an incorrect understanding of the file size and could
+corrupt data. This particularly happens when writing beyond the
+(supposed) end of file and can be easily be demonstrated with
+posix_fallocate().
+
+If an application opens an empty file, waits for a write lock, and then
+calls posix_fallocate(), glibc will determine that the underlying
+filesystem doesn't support fallocate (assuming version 4.1 or earlier)
+and will write out a '0' byte at the end of each 4K page in the region
+being fallocated that is after the end of the file.
+NFS will (usually) detect that these writes are beyond EOF and will
+expand them to cover the whole page, and then will merge the pages.
+Consequently, NFS will write out large blocks of zeroes beyond where it
+thought EOF was. If EOF had moved, the pre-existing part of the file
+will be over-written. Locking should have protected against this,
+but it doesn't.
+
+This patch restores the use of nfs_zap_caches() which invalidated the
+cached attributes. When posix_fallocate() asks for the file size, the
+request will go to the server and get a correct answer.
+
+Fixes: ca0daa277aca ("NFS: Cache aggressively when file is open for writing")
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfs/file.c
++++ b/fs/nfs/file.c
+@@ -750,7 +750,7 @@ do_setlk(struct file *filp, int cmd, str
+ */
+ nfs_sync_mapping(filp->f_mapping);
+ if (!NFS_PROTO(inode)->have_delegation(inode, FMODE_READ))
+- nfs_zap_mapping(inode, filp->f_mapping);
++ nfs_zap_caches(inode);
+ out:
+ return status;
+ }
--- /dev/null
+From b7dbcc0e433f0f61acb89ed9861ec996be4f2b38 Mon Sep 17 00:00:00 2001
+From: Benjamin Coddington <bcodding@redhat.com>
+Date: Fri, 28 Jul 2017 12:33:54 -0400
+Subject: NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter
+
+From: Benjamin Coddington <bcodding@redhat.com>
+
+commit b7dbcc0e433f0f61acb89ed9861ec996be4f2b38 upstream.
+
+nfs4_retry_setlk() sets the task's state to TASK_INTERRUPTIBLE within the
+same region protected by the wait_queue's lock after checking for a
+notification from CB_NOTIFY_LOCK callback. However, after releasing that
+lock, a wakeup for that task may race in before the call to
+freezable_schedule_timeout_interruptible() and set TASK_WAKING, then
+freezable_schedule_timeout_interruptible() will set the state back to
+TASK_INTERRUPTIBLE before the task will sleep. The result is that the task
+will sleep for the entire duration of the timeout.
+
+Since we've already set TASK_INTERRUPTIBLE in the locked section, just use
+freezable_schedule_timout() instead.
+
+Fixes: a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks")
+Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
+Reviewed-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -6441,7 +6441,7 @@ nfs4_retry_setlk(struct nfs4_state *stat
+ set_current_state(TASK_INTERRUPTIBLE);
+ spin_unlock_irqrestore(&q->lock, flags);
+
+- freezable_schedule_timeout_interruptible(NFS4_LOCK_MAXTIMEOUT);
++ freezable_schedule_timeout(NFS4_LOCK_MAXTIMEOUT);
+ }
+
+ finish_wait(q, &wait);
--- /dev/null
+From b4b201d88b7c9b3c6acdd03f9adec0c9857548ce Mon Sep 17 00:00:00 2001
+From: Frank Rowand <frank.rowand@sony.com>
+Date: Wed, 19 Jul 2017 18:35:31 -0700
+Subject: scripts/dtc: dtx_diff - update include dts paths to match build
+
+From: Frank Rowand <frank.rowand@sony.com>
+
+commit b4b201d88b7c9b3c6acdd03f9adec0c9857548ce upstream.
+
+Update the cpp include flags for compiling device tree dts files
+to match the changes made to the kernel build process in
+commit d5d332d3f7e8 ("devicetree: Move include prefixes from arch
+to separate directory").
+
+Signed-off-by: Frank Rowand <frank.rowand@sony.com>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/dtc/dtx_diff | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/dtc/dtx_diff
++++ b/scripts/dtc/dtx_diff
+@@ -321,7 +321,7 @@ fi
+ cpp_flags="\
+ -nostdinc \
+ -I${srctree}/arch/${ARCH}/boot/dts \
+- -I${srctree}/arch/${ARCH}/boot/dts/include \
++ -I${srctree}/scripts/dtc/include-prefixes \
+ -I${srctree}/drivers/of/testcase-data \
+ -undef -D__DTS__"
+
parisc-extend-disabled-preemption-in-copy_user_page.patch
parisc-suspend-lockup-detectors-before-system-halt.patch
powerpc-pseries-fix-of_node_put-underflow-during-reconfig-remove.patch
+mmc-sunxi-keep-default-timing-phase-settings-for-new-timing-mode.patch
+nfs-invalidate-file-size-when-taking-a-lock.patch
+nfsv4.1-fix-a-race-where-cb_notify_lock-fails-to-wake-a-waiter.patch
+scripts-dtc-dtx_diff-update-include-dts-paths-to-match-build.patch
+crypto-brcm-fix-sha3-512-algorithm-failure.patch
+crypto-brcm-remove-bcm_pdc_mbox-dependency-in-kconfig.patch
+crypto-authencesn-fix-digest_null-crash.patch
+kvm-ppc-book3s-hv-enable-tm-before-accessing-tm-registers.patch
+kvm-ppc-book3s-hv-fix-host-crash-on-changing-hpt-size.patch
+dm-integrity-fix-inefficient-allocation-of-journal-space.patch
+dm-integrity-test-for-corrupted-disk-format-during-table-load.patch
+md-remove-idx-from-struct-resync_pages.patch
+md-raid1-fix-writebehind-bio-clone.patch
+md-raid5-add-thread_group-worker-async_tx_issue_pending_all.patch
+drm-vmwgfx-fix-gcc-7.1.1-warning.patch
+drm-vmwgfx-limit-max-desktop-dimensions-to-8kx8k.patch
+drm-nouveau-disp-nv50-bump-max-chans-to-21.patch
+drm-nouveau-bar-gf100-fix-access-to-upper-half-of-bar2.patch
+drm-i915-fix-scaler-init-during-crtc-hw-state-readout.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
