--- /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 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 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
+@@ -2828,6 +2828,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 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
+@@ -5843,6 +5843,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 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
+@@ -757,7 +757,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
+@@ -6419,7 +6419,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);
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
+nfs-invalidate-file-size-when-taking-a-lock.patch
+nfsv4.1-fix-a-race-where-cb_notify_lock-fails-to-wake-a-waiter.patch
+crypto-authencesn-fix-digest_null-crash.patch
+kvm-ppc-book3s-hv-enable-tm-before-accessing-tm-registers.patch
+md-raid5-add-thread_group-worker-async_tx_issue_pending_all.patch
+drm-vmwgfx-fix-gcc-7.1.1-warning.patch
+drm-nouveau-disp-nv50-bump-max-chans-to-21.patch
+drm-nouveau-bar-gf100-fix-access-to-upper-half-of-bar2.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
