--- /dev/null
+From c0d762906f0e8159f550ac891d8fa78e497cbf36 Mon Sep 17 00:00:00 2001
+From: Young Xiao <YangX92@hotmail.com>
+Date: Fri, 12 Apr 2019 15:45:06 +0800
+Subject: Drivers: misc: fix out-of-bounds access in function
+ param_set_kgdbts_var
+
+[ Upstream commit b281218ad4311a0342a40cb02fb17a363df08b48 ]
+
+There is an out-of-bounds access to "config[len - 1]" array when the
+variable "len" is zero.
+
+See commit dada6a43b040 ("kgdboc: fix KASAN global-out-of-bounds bug
+in param_set_kgdboc_var()") for details.
+
+Signed-off-by: Young Xiao <YangX92@hotmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/misc/kgdbts.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
+index 99635dd9dbac..bb3a76ad80da 100644
+--- a/drivers/misc/kgdbts.c
++++ b/drivers/misc/kgdbts.c
+@@ -1132,7 +1132,7 @@ static void kgdbts_put_char(u8 chr)
+
+ static int param_set_kgdbts_var(const char *kmessage, struct kernel_param *kp)
+ {
+- int len = strlen(kmessage);
++ size_t len = strlen(kmessage);
+
+ if (len >= MAX_CONFIG_LEN) {
+ printk(KERN_ERR "kgdbts: config string too long\n");
+@@ -1152,7 +1152,7 @@ static int param_set_kgdbts_var(const char *kmessage, struct kernel_param *kp)
+
+ strcpy(config, kmessage);
+ /* Chop out \n char as a result of echo */
+- if (config[len - 1] == '\n')
++ if (len && config[len - 1] == '\n')
+ config[len - 1] = '\0';
+
+ /* Go and configure with the new params. */
+--
+2.20.1
+
--- /dev/null
+From 39a2efa9fa3c2b8eedcb9b619ea6d4a35af4a766 Mon Sep 17 00:00:00 2001
+From: Christian Borntraeger <borntraeger@de.ibm.com>
+Date: Fri, 24 May 2019 16:06:23 +0200
+Subject: KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
+
+[ Upstream commit 19ec166c3f39fe1d3789888a74cc95544ac266d4 ]
+
+kselftests exposed a problem in the s390 handling for memory slots.
+Right now we only do proper memory slot handling for creation of new
+memory slots. Neither MOVE, nor DELETION are handled properly. Let us
+implement those.
+
+Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kvm/kvm-s390.c | 35 +++++++++++++++++++++--------------
+ 1 file changed, 21 insertions(+), 14 deletions(-)
+
+diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
+index 5ddb1debba95..23911ecfbad6 100644
+--- a/arch/s390/kvm/kvm-s390.c
++++ b/arch/s390/kvm/kvm-s390.c
+@@ -2721,21 +2721,28 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
+ const struct kvm_memory_slot *new,
+ enum kvm_mr_change change)
+ {
+- int rc;
+-
+- /* If the basics of the memslot do not change, we do not want
+- * to update the gmap. Every update causes several unnecessary
+- * segment translation exceptions. This is usually handled just
+- * fine by the normal fault handler + gmap, but it will also
+- * cause faults on the prefix page of running guest CPUs.
+- */
+- if (old->userspace_addr == mem->userspace_addr &&
+- old->base_gfn * PAGE_SIZE == mem->guest_phys_addr &&
+- old->npages * PAGE_SIZE == mem->memory_size)
+- return;
++ int rc = 0;
+
+- rc = gmap_map_segment(kvm->arch.gmap, mem->userspace_addr,
+- mem->guest_phys_addr, mem->memory_size);
++ switch (change) {
++ case KVM_MR_DELETE:
++ rc = gmap_unmap_segment(kvm->arch.gmap, old->base_gfn * PAGE_SIZE,
++ old->npages * PAGE_SIZE);
++ break;
++ case KVM_MR_MOVE:
++ rc = gmap_unmap_segment(kvm->arch.gmap, old->base_gfn * PAGE_SIZE,
++ old->npages * PAGE_SIZE);
++ if (rc)
++ break;
++ /* FALLTHROUGH */
++ case KVM_MR_CREATE:
++ rc = gmap_map_segment(kvm->arch.gmap, mem->userspace_addr,
++ mem->guest_phys_addr, mem->memory_size);
++ break;
++ case KVM_MR_FLAGS_ONLY:
++ break;
++ default:
++ WARN(1, "Unknown KVM MR CHANGE: %d\n", change);
++ }
+ if (rc)
+ pr_warn("failed to commit memory region\n");
+ return;
+--
+2.20.1
+
--- /dev/null
+From a9c7f3aeebc202ede4a6b3ab6d6a9b7859182e1e Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Mon, 20 May 2019 17:34:30 +0200
+Subject: KVM: x86/pmu: do not mask the value that is written to fixed PMUs
+
+[ Upstream commit 2924b52117b2812e9633d5ea337333299166d373 ]
+
+According to the SDM, for MSR_IA32_PERFCTR0/1 "the lower-order 32 bits of
+each MSR may be written with any value, and the high-order 8 bits are
+sign-extended according to the value of bit 31", but the fixed counters
+in real hardware are limited to the width of the fixed counters ("bits
+beyond the width of the fixed-function counter are reserved and must be
+written as zeros"). Fix KVM to do the same.
+
+Reported-by: Nadav Amit <nadav.amit@gmail.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kvm/pmu_intel.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c
+index 23a7c7ba377a..8fc07ea23344 100644
+--- a/arch/x86/kvm/pmu_intel.c
++++ b/arch/x86/kvm/pmu_intel.c
+@@ -235,11 +235,14 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ }
+ break;
+ default:
+- if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) ||
+- (pmc = get_fixed_pmc(pmu, msr))) {
+- if (!msr_info->host_initiated)
+- data = (s64)(s32)data;
+- pmc->counter += data - pmc_read_counter(pmc);
++ if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0))) {
++ if (msr_info->host_initiated)
++ pmc->counter = data;
++ else
++ pmc->counter = (s32)data;
++ return 0;
++ } else if ((pmc = get_fixed_pmc(pmu, msr))) {
++ pmc->counter = data;
+ return 0;
+ } else if ((pmc = get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0))) {
+ if (data == pmc->eventsel)
+--
+2.20.1
+
--- /dev/null
+From 6e0007fe21b674e4bf2b73cacc9a0b4cf44f1301 Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Sat, 4 May 2019 17:48:29 +0100
+Subject: scsi: bnx2fc: fix incorrect cast to u64 on shift operation
+
+[ Upstream commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 ]
+
+Currently an int is being shifted and the result is being cast to a u64
+which leads to undefined behaviour if the shift is more than 31 bits. Fix
+this by casting the integer value 1 to u64 before the shift operation.
+
+Addresses-Coverity: ("Bad shift operation")
+Fixes: 7b594769120b ("[SCSI] bnx2fc: Handle REC_TOV error code from firmware")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Acked-by: Saurav Kashyap <skashyap@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
+index 28c671b609b2..0c71b69b9f88 100644
+--- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
++++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
+@@ -829,7 +829,7 @@ ret_err_rqe:
+ ((u64)err_entry->data.err_warn_bitmap_hi << 32) |
+ (u64)err_entry->data.err_warn_bitmap_lo;
+ for (i = 0; i < BNX2FC_NUM_ERR_BITS; i++) {
+- if (err_warn_bit_map & (u64) (1 << i)) {
++ if (err_warn_bit_map & ((u64)1 << i)) {
+ err_warn = i;
+ break;
+ }
+--
+2.20.1
+
--- /dev/null
+From be08989adbc549daa1dde4b00bd2c707453276ea Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Mon, 6 May 2019 17:26:49 -0700
+Subject: scsi: lpfc: add check for loss of ndlp when sending RRQ
+
+[ Upstream commit c8cb261a072c88ca1aff0e804a30db4c7606521b ]
+
+There was a missing qualification of a valid ndlp structure when calling to
+send an RRQ for an abort. Add the check.
+
+Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Tested-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/lpfc/lpfc_els.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
+index 398c9a0a5ade..82a690924f5e 100644
+--- a/drivers/scsi/lpfc/lpfc_els.c
++++ b/drivers/scsi/lpfc/lpfc_els.c
+@@ -6498,7 +6498,10 @@ int
+ lpfc_send_rrq(struct lpfc_hba *phba, struct lpfc_node_rrq *rrq)
+ {
+ struct lpfc_nodelist *ndlp = lpfc_findnode_did(rrq->vport,
+- rrq->nlp_DID);
++ rrq->nlp_DID);
++ if (!ndlp)
++ return 1;
++
+ if (lpfc_test_rrq_active(phba, ndlp, rrq->xritag))
+ return lpfc_issue_els_rrq(rrq->vport, ndlp,
+ rrq->nlp_DID, rrq);
+--
+2.20.1
+
bcache-fix-stack-corruption-by-preceding_key.patch
cgroup-use-css_tryget-instead-of-css_tryget_online-in-task_get_css.patch
asoc-cs42xx8-add-regcache-mask-dirty.patch
+drivers-misc-fix-out-of-bounds-access-in-function-pa.patch
+scsi-lpfc-add-check-for-loss-of-ndlp-when-sending-rr.patch
+scsi-bnx2fc-fix-incorrect-cast-to-u64-on-shift-opera.patch
+usbnet-ipheth-fix-racing-condition.patch
+kvm-x86-pmu-do-not-mask-the-value-that-is-written-to.patch
+kvm-s390-fix-memory-slot-handling-for-kvm_set_user_m.patch
--- /dev/null
+From 3204ad4db766e31fbb822bef2fe5708612007b02 Mon Sep 17 00:00:00 2001
+From: Bernd Eckstein <3erndeckstein@gmail.com>
+Date: Mon, 20 May 2019 17:31:09 +0200
+Subject: usbnet: ipheth: fix racing condition
+
+[ Upstream commit 94d250fae48e6f873d8362308f5c4d02cd1b1fd2 ]
+
+Fix a racing condition in ipheth.c that can lead to slow performance.
+
+Bug: In ipheth_tx(), netif_wake_queue() may be called on the callback
+ipheth_sndbulk_callback(), _before_ netif_stop_queue() is called.
+When this happens, the queue is stopped longer than it needs to be,
+thus reducing network performance.
+
+Fix: Move netif_stop_queue() in front of usb_submit_urb(). Now the order
+is always correct. In case, usb_submit_urb() fails, the queue is woken up
+again as callback will not fire.
+
+Testing: This racing condition is usually not noticeable, as it has to
+occur very frequently to slowdown the network. The callback from the USB
+is usually triggered slow enough, so the situation does not appear.
+However, on a Ubuntu Linux on VMWare Workstation, running on Windows 10,
+the we loose the race quite often and the following speedup can be noticed:
+
+Without this patch: Download: 4.10 Mbit/s, Upload: 4.01 Mbit/s
+With this patch: Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
+
+Signed-off-by: Oliver Zweigle <Oliver.Zweigle@faro.com>
+Signed-off-by: Bernd Eckstein <3ernd.Eckstein@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/ipheth.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
+index 01f95d192d25..2b16a5fed9de 100644
+--- a/drivers/net/usb/ipheth.c
++++ b/drivers/net/usb/ipheth.c
+@@ -437,17 +437,18 @@ static int ipheth_tx(struct sk_buff *skb, struct net_device *net)
+ dev);
+ dev->tx_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
+
++ netif_stop_queue(net);
+ retval = usb_submit_urb(dev->tx_urb, GFP_ATOMIC);
+ if (retval) {
+ dev_err(&dev->intf->dev, "%s: usb_submit_urb: %d\n",
+ __func__, retval);
+ dev->net->stats.tx_errors++;
+ dev_kfree_skb_any(skb);
++ netif_wake_queue(net);
+ } else {
+ dev->net->stats.tx_packets++;
+ dev->net->stats.tx_bytes += skb->len;
+ dev_consume_skb_any(skb);
+- netif_stop_queue(net);
+ }
+
+ return NETDEV_TX_OK;
+--
+2.20.1
+