--- /dev/null
+From f381c6a4bd0ae0fde2d6340f1b9bb0f58d915de6 Mon Sep 17 00:00:00 2001
+From: Andrea Parri <andrea.parri@amarulasolutions.com>
+Date: Mon, 20 May 2019 19:23:56 +0200
+Subject: bio: fix improper use of smp_mb__before_atomic()
+
+From: Andrea Parri <andrea.parri@amarulasolutions.com>
+
+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" <paulmck@linux.ibm.com>
+Reported-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: linux-block@vger.kernel.org
+Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/bio.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/bio.h
++++ b/include/linux/bio.h
+@@ -211,7 +211,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);
+ }
--- /dev/null
+From e1354400b25da645c4764ed6844d12f1582c3b66 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 14 May 2019 16:13:15 -0700
+Subject: crypto: hash - fix incorrect HASH_MAX_DESCSIZE
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit e1354400b25da645c4764ed6844d12f1582c3b66 upstream.
+
+The "hmac(sha3-224-generic)" algorithm has a descsize of 368 bytes,
+which is greater than HASH_MAX_DESCSIZE (360) which is only enough for
+sha3-224-generic. The check in shash_prepare_alg() doesn't catch this
+because the HMAC template doesn't set descsize on the algorithms, but
+rather sets it on each individual HMAC transform.
+
+This causes a stack buffer overflow when SHASH_DESC_ON_STACK() is used
+with hmac(sha3-224-generic).
+
+Fix it by increasing HASH_MAX_DESCSIZE to the real maximum. Also add a
+sanity check to hmac_init().
+
+This was detected by the improved crypto self-tests in v5.2, by loading
+the tcrypt module with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y enabled. I
+didn't notice this bug when I ran the self-tests by requesting the
+algorithms via AF_ALG (i.e., not using tcrypt), probably because the
+stack layout differs in the two cases and that made a difference here.
+
+KASAN report:
+
+ BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:359 [inline]
+ BUG: KASAN: stack-out-of-bounds in shash_default_import+0x52/0x80 crypto/shash.c:223
+ Write of size 360 at addr ffff8880651defc8 by task insmod/3689
+
+ CPU: 2 PID: 3689 Comm: insmod Tainted: G E 5.1.0-10741-g35c99ffa20edd #11
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
+ Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x86/0xc5 lib/dump_stack.c:113
+ print_address_description+0x7f/0x260 mm/kasan/report.c:188
+ __kasan_report+0x144/0x187 mm/kasan/report.c:317
+ kasan_report+0x12/0x20 mm/kasan/common.c:614
+ check_memory_region_inline mm/kasan/generic.c:185 [inline]
+ check_memory_region+0x137/0x190 mm/kasan/generic.c:191
+ memcpy+0x37/0x50 mm/kasan/common.c:125
+ memcpy include/linux/string.h:359 [inline]
+ shash_default_import+0x52/0x80 crypto/shash.c:223
+ crypto_shash_import include/crypto/hash.h:880 [inline]
+ hmac_import+0x184/0x240 crypto/hmac.c:102
+ hmac_init+0x96/0xc0 crypto/hmac.c:107
+ crypto_shash_init include/crypto/hash.h:902 [inline]
+ shash_digest_unaligned+0x9f/0xf0 crypto/shash.c:194
+ crypto_shash_digest+0xe9/0x1b0 crypto/shash.c:211
+ generate_random_hash_testvec.constprop.11+0x1ec/0x5b0 crypto/testmgr.c:1331
+ test_hash_vs_generic_impl+0x3f7/0x5c0 crypto/testmgr.c:1420
+ __alg_test_hash+0x26d/0x340 crypto/testmgr.c:1502
+ alg_test_hash+0x22e/0x330 crypto/testmgr.c:1552
+ alg_test.part.7+0x132/0x610 crypto/testmgr.c:4931
+ alg_test+0x1f/0x40 crypto/testmgr.c:4952
+
+Fixes: b68a7ec1e9a3 ("crypto: hash - Remove VLA usage")
+Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
+Cc: <stable@vger.kernel.org> # v4.20+
+Cc: Kees Cook <keescook@chromium.org>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/hmac.c | 2 ++
+ include/crypto/hash.h | 8 +++++++-
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/crypto/hmac.c
++++ b/crypto/hmac.c
+@@ -168,6 +168,8 @@ static int hmac_init_tfm(struct crypto_t
+
+ parent->descsize = sizeof(struct shash_desc) +
+ crypto_shash_descsize(hash);
++ if (WARN_ON(parent->descsize > HASH_MAX_DESCSIZE))
++ return -EINVAL;
+
+ ctx->hash = hash;
+ return 0;
+--- a/include/crypto/hash.h
++++ b/include/crypto/hash.h
+@@ -152,7 +152,13 @@ struct shash_desc {
+ };
+
+ #define HASH_MAX_DIGESTSIZE 64
+-#define HASH_MAX_DESCSIZE 360
++
++/*
++ * Worst case is hmac(sha3-224-generic). Its context is a nested 'shash_desc'
++ * containing a 'struct sha3_state'.
++ */
++#define HASH_MAX_DESCSIZE (sizeof(struct shash_desc) + 360)
++
+ #define HASH_MAX_STATESIZE 512
+
+ #define SHASH_DESC_ON_STACK(shash, ctx) \
--- /dev/null
+From 009b30ac7444c17fae34c4f435ebce8e8e2b3250 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens <dja@axtens.net>
+Date: Wed, 15 May 2019 20:24:50 +1000
+Subject: crypto: vmx - CTR: always increment IV as quadword
+
+From: Daniel Axtens <dja@axtens.net>
+
+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 <dja@axtens.net>
+Acked-by: Nayna Jain <nayna@linux.ibm.com>
+Tested-by: Nayna Jain <nayna@linux.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1357,7 +1357,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
--- /dev/null
+From c9bcd3e3335d0a29d89fabd2c385e1b989e6f1b0 Mon Sep 17 00:00:00 2001
+From: "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@amd.com>
+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 <Suravee.Suthikulpanit@amd.com>
+
+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 <suravee.suthikulpanit@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -2020,7 +2020,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));
--- /dev/null
+From 66f61c92889ff3ca365161fb29dd36d6354682ba Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Fri, 24 May 2019 21:52:46 +0200
+Subject: KVM: x86: fix return value for reserved EFER
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+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 <pavel@denx.de>
+Fixes: 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes")
+Cc: Sean Christopherson <sean.j.christopherson@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1288,7 +1288,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))
--- /dev/null
+From 52f476a323f9efc959be1c890d0cdcf12e1582e0 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Thu, 16 May 2019 17:05:21 -0700
+Subject: libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 52f476a323f9efc959be1c890d0cdcf12e1582e0 upstream.
+
+Jeff discovered that performance improves from ~375K iops to ~519K iops
+on a simple psync-write fio workload when moving the location of 'struct
+page' from the default PMEM location to DRAM. This result is surprising
+because the expectation is that 'struct page' for dax is only needed for
+third party references to dax mappings. For example, a dax-mapped buffer
+passed to another system call for direct-I/O requires 'struct page' for
+sending the request down the driver stack and pinning the page. There is
+no usage of 'struct page' for first party access to a file via
+read(2)/write(2) and friends.
+
+However, this "no page needed" expectation is violated by
+CONFIG_HARDENED_USERCOPY and the check_copy_size() performed in
+copy_from_iter_full_nocache() and copy_to_iter_mcsafe(). The
+check_heap_object() helper routine assumes the buffer is backed by a
+slab allocator (DRAM) page and applies some checks. Those checks are
+invalid, dax pages do not originate from the slab, and redundant,
+dax_iomap_actor() has already validated that the I/O is within bounds.
+Specifically that routine validates that the logical file offset is
+within bounds of the file, then it does a sector-to-pfn translation
+which validates that the physical mapping is within bounds of the block
+device.
+
+Bypass additional hardened usercopy overhead and call the 'no check'
+versions of the copy_{to,from}_iter operations directly.
+
+Fixes: 0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache...")
+Cc: <stable@vger.kernel.org>
+Cc: Jeff Moyer <jmoyer@redhat.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Matthew Wilcox <willy@infradead.org>
+Reported-and-tested-by: Jeff Smits <jeff.smits@intel.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvdimm/pmem.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/nvdimm/pmem.c
++++ b/drivers/nvdimm/pmem.c
+@@ -281,16 +281,22 @@ static long pmem_dax_direct_access(struc
+ return __pmem_direct_access(pmem, pgoff, nr_pages, kaddr, pfn);
+ }
+
++/*
++ * Use the 'no check' versions of copy_from_iter_flushcache() and
++ * copy_to_iter_mcsafe() to bypass HARDENED_USERCOPY overhead. Bounds
++ * checking, both file offset and device offset, is handled by
++ * dax_iomap_actor()
++ */
+ static size_t pmem_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff,
+ void *addr, size_t bytes, struct iov_iter *i)
+ {
+- return copy_from_iter_flushcache(addr, bytes, i);
++ return _copy_from_iter_flushcache(addr, bytes, i);
+ }
+
+ static size_t pmem_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff,
+ void *addr, size_t bytes, struct iov_iter *i)
+ {
+- return copy_to_iter_mcsafe(addr, bytes, i);
++ return _copy_to_iter_mcsafe(addr, bytes, i);
+ }
+
+ static const struct dax_operations pmem_dax_ops = {
--- /dev/null
+From b7dfa695afc40d5396ed84b9f25aa3754de23e39 Mon Sep 17 00:00:00 2001
+From: Trac Hoang <trac.hoang@broadcom.com>
+Date: Thu, 9 May 2019 10:24:26 -0700
+Subject: mmc: sdhci-iproc: cygnus: Set NO_HISPD bit to fix HS50 data hold time problem
+
+From: Trac Hoang <trac.hoang@broadcom.com>
+
+commit b7dfa695afc40d5396ed84b9f25aa3754de23e39 upstream.
+
+The iproc host eMMC/SD controller hold time does not meet the
+specification in the HS50 mode. This problem can be mitigated
+by disabling the HISPD bit; thus forcing the controller output
+data to be driven on the falling clock edges rather than the
+rising clock edges.
+
+This change applies only to the Cygnus platform.
+
+Stable tag (v4.12+) chosen to assist stable kernel maintainers so that
+the change does not produce merge conflicts backporting to older kernel
+versions. In reality, the timing bug existed since the driver was first
+introduced but there is no need for this driver to be supported in kernel
+versions that old.
+
+Cc: stable@vger.kernel.org # v4.12+
+Signed-off-by: Trac Hoang <trac.hoang@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -196,7 +196,8 @@ static const struct sdhci_ops sdhci_ipro
+ };
+
+ static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
+- .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
++ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
++ SDHCI_QUIRK_NO_HISPD_BIT,
+ .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN | SDHCI_QUIRK2_HOST_OFF_CARD_ON,
+ .ops = &sdhci_iproc_32only_ops,
+ };
--- /dev/null
+From ec0970e0a1b2c807c908d459641a9f9a1be3e130 Mon Sep 17 00:00:00 2001
+From: Trac Hoang <trac.hoang@broadcom.com>
+Date: Thu, 9 May 2019 10:24:27 -0700
+Subject: mmc: sdhci-iproc: Set NO_HISPD bit to fix HS50 data hold time problem
+
+From: Trac Hoang <trac.hoang@broadcom.com>
+
+commit ec0970e0a1b2c807c908d459641a9f9a1be3e130 upstream.
+
+The iproc host eMMC/SD controller hold time does not meet the
+specification in the HS50 mode. This problem can be mitigated
+by disabling the HISPD bit; thus forcing the controller output
+data to be driven on the falling clock edges rather than the
+rising clock edges.
+
+Stable tag (v4.12+) chosen to assist stable kernel maintainers so that
+the change does not produce merge conflicts backporting to older kernel
+versions. In reality, the timing bug existed since the driver was first
+introduced but there is no need for this driver to be supported in kernel
+versions that old.
+
+Cc: stable@vger.kernel.org # v4.12+
+Signed-off-by: Trac Hoang <trac.hoang@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -220,7 +220,8 @@ static const struct sdhci_iproc_data ipr
+
+ static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
+ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
+- SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
++ SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 |
++ SDHCI_QUIRK_NO_HISPD_BIT,
+ .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
+ .ops = &sdhci_iproc_ops,
+ };
--- /dev/null
+From 8acf608e602f6ec38b7cc37b04c80f1ce9a1a6cc Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+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 <martin.petersen@oracle.com>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -2586,7 +2586,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);
+@@ -2627,7 +2626,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");
--- /dev/null
+From a0934fd2b1208458e55fc4b48f55889809fce666 Mon Sep 17 00:00:00 2001
+From: Andrea Parri <andrea.parri@amarulasolutions.com>
+Date: Mon, 20 May 2019 19:23:57 +0200
+Subject: sbitmap: fix improper use of smp_mb__before_atomic()
+
+From: Andrea Parri <andrea.parri@amarulasolutions.com>
+
+commit a0934fd2b1208458e55fc4b48f55889809fce666 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: 6c0ca7ae292ad ("sbitmap: fix wakeup hang after sbq resize")
+Cc: stable@vger.kernel.org
+Reported-by: "Paul E. McKenney" <paulmck@linux.ibm.com>
+Reported-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Omar Sandoval <osandov@fb.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: linux-block@vger.kernel.org
+Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/sbitmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/lib/sbitmap.c
++++ b/lib/sbitmap.c
+@@ -435,7 +435,7 @@ static void sbitmap_queue_update_wake_ba
+ * to ensure that the batch size is updated before the wait
+ * counts.
+ */
+- smp_mb__before_atomic();
++ smp_mb();
+ for (i = 0; i < SBQ_WAIT_QUEUES; i++)
+ atomic_set(&sbq->ws[i].wait_cnt, 1);
+ }
x86-hide-the-int3_emulate_call-jmp-functions-from-uml.patch
ext4-do-not-delete-unlinked-inode-from-orphan-list-on-failed-truncate.patch
ext4-wait-for-outstanding-dio-during-truncate-in-nojournal-mode.patch
+kvm-x86-fix-return-value-for-reserved-efer.patch
+bio-fix-improper-use-of-smp_mb__before_atomic.patch
+sbitmap-fix-improper-use-of-smp_mb__before_atomic.patch
+revert-scsi-sd-keep-disk-read-only-when-re-reading-partition.patch
+crypto-hash-fix-incorrect-hash_max_descsize.patch
+crypto-vmx-ctr-always-increment-iv-as-quadword.patch
+mmc-sdhci-iproc-cygnus-set-no_hispd-bit-to-fix-hs50-data-hold-time-problem.patch
+mmc-sdhci-iproc-set-no_hispd-bit-to-fix-hs50-data-hold-time-problem.patch
+kvm-svm-avic-fix-off-by-one-in-checking-host-apic-id.patch
+libnvdimm-pmem-bypass-config_hardened_usercopy-overhead.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
