From: Greg Kroah-Hartman Date: Mon, 27 May 2019 12:11:57 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v5.1.6~43 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=484c4e843c8fb7228167724380fabe13cb2bbfab;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: bio-fix-improper-use-of-smp_mb__before_atomic.patch crypto-vmx-ctr-always-increment-iv-as-quadword.patch kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch kvm-x86-fix-return-value-for-reserved-efer.patch libnvdimm-namespace-fix-label-tracking-error.patch revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch --- diff --git a/queue-4.9/bio-fix-improper-use-of-smp_mb__before_atomic.patch b/queue-4.9/bio-fix-improper-use-of-smp_mb__before_atomic.patch new file mode 100644 index 0000000000..e5d6c12053 --- /dev/null +++ b/queue-4.9/bio-fix-improper-use-of-smp_mb__before_atomic.patch @@ -0,0 +1,43 @@ +From f381c6a4bd0ae0fde2d6340f1b9bb0f58d915de6 Mon Sep 17 00:00:00 2001 +From: Andrea Parri +Date: Mon, 20 May 2019 19:23:56 +0200 +Subject: bio: fix improper use of smp_mb__before_atomic() + +From: Andrea Parri + +commit f381c6a4bd0ae0fde2d6340f1b9bb0f58d915de6 upstream. + +This barrier only applies to the read-modify-write operations; in +particular, it does not apply to the atomic_set() primitive. + +Replace the barrier with an smp_mb(). + +Fixes: dac56212e8127 ("bio: skip atomic inc/dec of ->bi_cnt for most use cases") +Cc: stable@vger.kernel.org +Reported-by: "Paul E. McKenney" +Reported-by: Peter Zijlstra +Signed-off-by: Andrea Parri +Reviewed-by: Ming Lei +Cc: Jens Axboe +Cc: Ming Lei +Cc: linux-block@vger.kernel.org +Cc: "Paul E. McKenney" +Cc: Peter Zijlstra +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/bio.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/bio.h ++++ b/include/linux/bio.h +@@ -237,7 +237,7 @@ static inline void bio_cnt_set(struct bi + { + if (count != 1) { + bio->bi_flags |= (1 << BIO_REFFED); +- smp_mb__before_atomic(); ++ smp_mb(); + } + atomic_set(&bio->__bi_cnt, count); + } diff --git a/queue-4.9/crypto-vmx-ctr-always-increment-iv-as-quadword.patch b/queue-4.9/crypto-vmx-ctr-always-increment-iv-as-quadword.patch new file mode 100644 index 0000000000..042fc81c36 --- /dev/null +++ b/queue-4.9/crypto-vmx-ctr-always-increment-iv-as-quadword.patch @@ -0,0 +1,57 @@ +From 009b30ac7444c17fae34c4f435ebce8e8e2b3250 Mon Sep 17 00:00:00 2001 +From: Daniel Axtens +Date: Wed, 15 May 2019 20:24:50 +1000 +Subject: crypto: vmx - CTR: always increment IV as quadword + +From: Daniel Axtens + +commit 009b30ac7444c17fae34c4f435ebce8e8e2b3250 upstream. + +The kernel self-tests picked up an issue with CTR mode: +alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep" + +Test vector 3 has an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD, so +after 3 increments it should wrap around to 0. + +In the aesp8-ppc code from OpenSSL, there are two paths that +increment IVs: the bulk (8 at a time) path, and the individual +path which is used when there are fewer than 8 AES blocks to +process. + +In the bulk path, the IV is incremented with vadduqm: "Vector +Add Unsigned Quadword Modulo", which does 128-bit addition. + +In the individual path, however, the IV is incremented with +vadduwm: "Vector Add Unsigned Word Modulo", which instead +does 4 32-bit additions. Thus the IV would instead become +FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result. + +Use vadduqm. + +This was probably a typo originally, what with q and w being +adjacent. It is a pretty narrow edge case: I am really +impressed by the quality of the kernel self-tests! + +Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM") +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Axtens +Acked-by: Nayna Jain +Tested-by: Nayna Jain +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/vmx/aesp8-ppc.pl | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/crypto/vmx/aesp8-ppc.pl ++++ b/drivers/crypto/vmx/aesp8-ppc.pl +@@ -1318,7 +1318,7 @@ Loop_ctr32_enc: + addi $idx,$idx,16 + bdnz Loop_ctr32_enc + +- vadduwm $ivec,$ivec,$one ++ vadduqm $ivec,$ivec,$one + vmr $dat,$inptail + lvx $inptail,0,$inp + addi $inp,$inp,16 diff --git a/queue-4.9/kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch b/queue-4.9/kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch new file mode 100644 index 0000000000..b485042a80 --- /dev/null +++ b/queue-4.9/kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch @@ -0,0 +1,43 @@ +From c9bcd3e3335d0a29d89fabd2c385e1b989e6f1b0 Mon Sep 17 00:00:00 2001 +From: "Suthikulpanit, Suravee" +Date: Tue, 14 May 2019 15:49:52 +0000 +Subject: kvm: svm/avic: fix off-by-one in checking host APIC ID + +From: Suthikulpanit, Suravee + +commit c9bcd3e3335d0a29d89fabd2c385e1b989e6f1b0 upstream. + +Current logic does not allow VCPU to be loaded onto CPU with +APIC ID 255. This should be allowed since the host physical APIC ID +field in the AVIC Physical APIC table entry is an 8-bit value, +and APIC ID 255 is valid in system with x2APIC enabled. +Instead, do not allow VCPU load if the host APIC ID cannot be +represented by an 8-bit value. + +Also, use the more appropriate AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK +instead of AVIC_MAX_PHYSICAL_ID_COUNT. + +Signed-off-by: Suravee Suthikulpanit +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/svm.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm.c ++++ b/arch/x86/kvm/svm.c +@@ -1518,7 +1518,11 @@ static void avic_vcpu_load(struct kvm_vc + if (!kvm_vcpu_apicv_active(vcpu)) + return; + +- if (WARN_ON(h_physical_id >= AVIC_MAX_PHYSICAL_ID_COUNT)) ++ /* ++ * Since the host physical APIC id is 8 bits, ++ * we can support host APIC ID upto 255. ++ */ ++ if (WARN_ON(h_physical_id > AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK)) + return; + + entry = READ_ONCE(*(svm->avic_physical_id_cache)); diff --git a/queue-4.9/kvm-x86-fix-return-value-for-reserved-efer.patch b/queue-4.9/kvm-x86-fix-return-value-for-reserved-efer.patch new file mode 100644 index 0000000000..8007bef64c --- /dev/null +++ b/queue-4.9/kvm-x86-fix-return-value-for-reserved-efer.patch @@ -0,0 +1,36 @@ +From 66f61c92889ff3ca365161fb29dd36d6354682ba Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 24 May 2019 21:52:46 +0200 +Subject: KVM: x86: fix return value for reserved EFER + +From: Paolo Bonzini + +commit 66f61c92889ff3ca365161fb29dd36d6354682ba upstream. + +Commit 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID checks for +host-initiated writes", 2019-04-02) introduced a "return false" in a +function returning int, and anyway set_efer has a "nonzero on error" +conventon so it should be returning 1. + +Reported-by: Pavel Machek +Fixes: 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes") +Cc: Sean Christopherson +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -1109,7 +1109,7 @@ static int set_efer(struct kvm_vcpu *vcp + u64 efer = msr_info->data; + + if (efer & efer_reserved_bits) +- return false; ++ return 1; + + if (!msr_info->host_initiated) { + if (!__kvm_valid_efer(vcpu, efer)) diff --git a/queue-4.9/libnvdimm-namespace-fix-label-tracking-error.patch b/queue-4.9/libnvdimm-namespace-fix-label-tracking-error.patch new file mode 100644 index 0000000000..d21858d983 --- /dev/null +++ b/queue-4.9/libnvdimm-namespace-fix-label-tracking-error.patch @@ -0,0 +1,158 @@ +From c4703ce11c23423d4b46e3d59aef7979814fd608 Mon Sep 17 00:00:00 2001 +From: Dan Williams +Date: Tue, 30 Apr 2019 21:51:21 -0700 +Subject: libnvdimm/namespace: Fix label tracking error + +From: Dan Williams + +commit c4703ce11c23423d4b46e3d59aef7979814fd608 upstream. + +Users have reported intermittent occurrences of DIMM initialization +failures due to duplicate allocations of address capacity detected in +the labels, or errors of the form below, both have the same root cause. + + nd namespace1.4: failed to track label: 0 + WARNING: CPU: 17 PID: 1381 at drivers/nvdimm/label.c:863 + + RIP: 0010:__pmem_label_update+0x56c/0x590 [libnvdimm] + Call Trace: + ? nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm] + nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm] + uuid_store+0x17e/0x190 [libnvdimm] + kernfs_fop_write+0xf0/0x1a0 + vfs_write+0xb7/0x1b0 + ksys_write+0x57/0xd0 + do_syscall_64+0x60/0x210 + +Unfortunately those reports were typically with a busy parallel +namespace creation / destruction loop making it difficult to see the +components of the bug. However, Jane provided a simple reproducer using +the work-in-progress sub-section implementation. + +When ndctl is reconfiguring a namespace it may take an existing defunct +/ disabled namespace and reconfigure it with a new uuid and other +parameters. Critically namespace_update_uuid() takes existing address +resources and renames them for the new namespace to use / reconfigure as +it sees fit. The bug is that this rename only happens in the resource +tracking tree. Existing labels with the old uuid are not reaped leading +to a scenario where multiple active labels reference the same span of +address range. + +Teach namespace_update_uuid() to flag any references to the old uuid for +reaping at the next label update attempt. + +Cc: +Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace instantiation") +Link: https://github.com/pmem/ndctl/issues/91 +Reported-by: Jane Chu +Reported-by: Jeff Moyer +Reported-by: Erwin Tsaur +Cc: Johannes Thumshirn +Signed-off-by: Dan Williams +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/nvdimm/label.c | 29 ++++++++++++++++------------- + drivers/nvdimm/namespace_devs.c | 15 +++++++++++++++ + drivers/nvdimm/nd.h | 4 ++++ + 3 files changed, 35 insertions(+), 13 deletions(-) + +--- a/drivers/nvdimm/label.c ++++ b/drivers/nvdimm/label.c +@@ -490,15 +490,26 @@ static unsigned long nd_label_offset(str + - (unsigned long) to_namespace_index(ndd, 0); + } + ++static void reap_victim(struct nd_mapping *nd_mapping, ++ struct nd_label_ent *victim) ++{ ++ struct nvdimm_drvdata *ndd = to_ndd(nd_mapping); ++ u32 slot = to_slot(ndd, victim->label); ++ ++ dev_dbg(ndd->dev, "free: %d\n", slot); ++ nd_label_free_slot(ndd, slot); ++ victim->label = NULL; ++} ++ + static int __pmem_label_update(struct nd_region *nd_region, + struct nd_mapping *nd_mapping, struct nd_namespace_pmem *nspm, + int pos, unsigned long flags) + { + u64 cookie = nd_region_interleave_set_cookie(nd_region); + struct nvdimm_drvdata *ndd = to_ndd(nd_mapping); +- struct nd_label_ent *label_ent, *victim = NULL; + struct nd_namespace_label *nd_label; + struct nd_namespace_index *nsindex; ++ struct nd_label_ent *label_ent; + struct nd_label_id label_id; + struct resource *res; + unsigned long *free; +@@ -551,18 +562,10 @@ static int __pmem_label_update(struct nd + list_for_each_entry(label_ent, &nd_mapping->labels, list) { + if (!label_ent->label) + continue; +- if (memcmp(nspm->uuid, label_ent->label->uuid, +- NSLABEL_UUID_LEN) != 0) +- continue; +- victim = label_ent; +- list_move_tail(&victim->list, &nd_mapping->labels); +- break; +- } +- if (victim) { +- dev_dbg(ndd->dev, "%s: free: %d\n", __func__, slot); +- slot = to_slot(ndd, victim->label); +- nd_label_free_slot(ndd, slot); +- victim->label = NULL; ++ if (test_and_clear_bit(ND_LABEL_REAP, &label_ent->flags) ++ || memcmp(nspm->uuid, label_ent->label->uuid, ++ NSLABEL_UUID_LEN) == 0) ++ reap_victim(nd_mapping, label_ent); + } + + /* update index */ +--- a/drivers/nvdimm/namespace_devs.c ++++ b/drivers/nvdimm/namespace_devs.c +@@ -1210,12 +1210,27 @@ static int namespace_update_uuid(struct + for (i = 0; i < nd_region->ndr_mappings; i++) { + struct nd_mapping *nd_mapping = &nd_region->mapping[i]; + struct nvdimm_drvdata *ndd = to_ndd(nd_mapping); ++ struct nd_label_ent *label_ent; + struct resource *res; + + for_each_dpa_resource(ndd, res) + if (strcmp(res->name, old_label_id.id) == 0) + sprintf((void *) res->name, "%s", + new_label_id.id); ++ ++ mutex_lock(&nd_mapping->lock); ++ list_for_each_entry(label_ent, &nd_mapping->labels, list) { ++ struct nd_namespace_label *nd_label = label_ent->label; ++ struct nd_label_id label_id; ++ ++ if (!nd_label) ++ continue; ++ nd_label_gen_id(&label_id, nd_label->uuid, ++ __le32_to_cpu(nd_label->flags)); ++ if (strcmp(old_label_id.id, label_id.id) == 0) ++ set_bit(ND_LABEL_REAP, &label_ent->flags); ++ } ++ mutex_unlock(&nd_mapping->lock); + } + kfree(*old_uuid); + out: +--- a/drivers/nvdimm/nd.h ++++ b/drivers/nvdimm/nd.h +@@ -113,8 +113,12 @@ struct nd_percpu_lane { + spinlock_t lock; + }; + ++enum nd_label_flags { ++ ND_LABEL_REAP, ++}; + struct nd_label_ent { + struct list_head list; ++ unsigned long flags; + struct nd_namespace_label *label; + }; + diff --git a/queue-4.9/revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch b/queue-4.9/revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch new file mode 100644 index 0000000000..cd1f5d2885 --- /dev/null +++ b/queue-4.9/revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch @@ -0,0 +1,51 @@ +From 8acf608e602f6ec38b7cc37b04c80f1ce9a1a6cc Mon Sep 17 00:00:00 2001 +From: "Martin K. Petersen" +Date: Mon, 20 May 2019 10:57:18 -0400 +Subject: Revert "scsi: sd: Keep disk read-only when re-reading partition" + +From: Martin K. Petersen + +commit 8acf608e602f6ec38b7cc37b04c80f1ce9a1a6cc upstream. + +This reverts commit 20bd1d026aacc5399464f8328f305985c493cde3. + +This patch introduced regressions for devices that come online in +read-only state and subsequently switch to read-write. + +Given how the partition code is currently implemented it is not +possible to persist the read-only flag across a device revalidate +call. This may need to get addressed in the future since it is common +for user applications to proactively call BLKRRPART. + +Reverting this commit will re-introduce a regression where a +device-initiated revalidate event will cause the admin state to be +forgotten. A separate patch will address this issue. + +Fixes: 20bd1d026aac ("scsi: sd: Keep disk read-only when re-reading partition") +Cc: +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/sd.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/scsi/sd.c ++++ b/drivers/scsi/sd.c +@@ -2403,7 +2403,6 @@ sd_read_write_protect_flag(struct scsi_d + int res; + struct scsi_device *sdp = sdkp->device; + struct scsi_mode_data data; +- int disk_ro = get_disk_ro(sdkp->disk); + int old_wp = sdkp->write_prot; + + set_disk_ro(sdkp->disk, 0); +@@ -2444,7 +2443,7 @@ sd_read_write_protect_flag(struct scsi_d + "Test WP failed, assume Write Enabled\n"); + } else { + sdkp->write_prot = ((data.device_specific & 0x80) != 0); +- set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro); ++ set_disk_ro(sdkp->disk, sdkp->write_prot); + if (sdkp->first_scan || old_wp != sdkp->write_prot) { + sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n", + sdkp->write_prot ? "on" : "off"); diff --git a/queue-4.9/series b/queue-4.9/series index 36815308b0..5351279962 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -1 +1,7 @@ ext4-do-not-delete-unlinked-inode-from-orphan-list-on-failed-truncate.patch +kvm-x86-fix-return-value-for-reserved-efer.patch +bio-fix-improper-use-of-smp_mb__before_atomic.patch +revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch +crypto-vmx-ctr-always-increment-iv-as-quadword.patch +kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch +libnvdimm-namespace-fix-label-tracking-error.patch