--- /dev/null
+From 2d012c65a9ca26a0ef87ea0a42f1653dd37155f5 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Sun, 17 Mar 2019 15:49:29 +0900
+Subject: ALSA: firewire-motu: use 'version' field of unit directory to identify model
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 2d012c65a9ca26a0ef87ea0a42f1653dd37155f5 upstream.
+
+Current ALSA firewire-motu driver uses the value of 'model' field
+of unit directory in configuration ROM for modalias for MOTU
+FireWire models. However, as long as I checked, Pre8 and
+828mk3(Hybrid) have the same value for the field (=0x100800).
+
+unit | version | model
+--------------- | --------- | ----------
+828mkII | 0x000003 | 0x101800
+Traveler | 0x000009 | 0x107800
+Pre8 | 0x00000f | 0x100800 <-
+828mk3(FW) | 0x000015 | 0x106800
+AudioExpress | 0x000033 | 0x104800
+828mk3(Hybrid) | 0x000035 | 0x100800 <-
+
+When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3,
+I got change of the value from 0x100800 to 0x103800. On the other
+hand, the value of 'version' field is fixed to 0x00000f. As a quick
+glance, the higher 12 bits of the value of 'version' field represent
+firmware version, while the lower 12 bits is unknown.
+
+By induction, the value of 'version' field represents actual model.
+
+This commit changes modalias to match the value of 'version' field,
+instead of 'model' field. For degug, long name of added sound card
+includes hexadecimal value of 'model' field.
+
+Fixes: 6c5e1ac0e144 ("ALSA: firewire-motu: add support for Motu Traveler")
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Cc: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/firewire/motu/motu.c | 20 ++++++++++----------
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+--- a/sound/firewire/motu/motu.c
++++ b/sound/firewire/motu/motu.c
+@@ -36,7 +36,7 @@ static void name_card(struct snd_motu *m
+ fw_csr_iterator_init(&it, motu->unit->directory);
+ while (fw_csr_iterator_next(&it, &key, &val)) {
+ switch (key) {
+- case CSR_VERSION:
++ case CSR_MODEL:
+ version = val;
+ break;
+ }
+@@ -46,7 +46,7 @@ static void name_card(struct snd_motu *m
+ strcpy(motu->card->shortname, motu->spec->name);
+ strcpy(motu->card->mixername, motu->spec->name);
+ snprintf(motu->card->longname, sizeof(motu->card->longname),
+- "MOTU %s (version:%d), GUID %08x%08x at %s, S%d",
++ "MOTU %s (version:%06x), GUID %08x%08x at %s, S%d",
+ motu->spec->name, version,
+ fw_dev->config_rom[3], fw_dev->config_rom[4],
+ dev_name(&motu->unit->device), 100 << fw_dev->max_speed);
+@@ -237,20 +237,20 @@ static const struct snd_motu_spec motu_a
+ #define SND_MOTU_DEV_ENTRY(model, data) \
+ { \
+ .match_flags = IEEE1394_MATCH_VENDOR_ID | \
+- IEEE1394_MATCH_MODEL_ID | \
+- IEEE1394_MATCH_SPECIFIER_ID, \
++ IEEE1394_MATCH_SPECIFIER_ID | \
++ IEEE1394_MATCH_VERSION, \
+ .vendor_id = OUI_MOTU, \
+- .model_id = model, \
+ .specifier_id = OUI_MOTU, \
++ .version = model, \
+ .driver_data = (kernel_ulong_t)data, \
+ }
+
+ static const struct ieee1394_device_id motu_id_table[] = {
+- SND_MOTU_DEV_ENTRY(0x101800, &motu_828mk2),
+- SND_MOTU_DEV_ENTRY(0x107800, &snd_motu_spec_traveler),
+- SND_MOTU_DEV_ENTRY(0x106800, &motu_828mk3), /* FireWire only. */
+- SND_MOTU_DEV_ENTRY(0x100800, &motu_828mk3), /* Hybrid. */
+- SND_MOTU_DEV_ENTRY(0x104800, &motu_audio_express),
++ SND_MOTU_DEV_ENTRY(0x000003, &motu_828mk2),
++ SND_MOTU_DEV_ENTRY(0x000009, &snd_motu_spec_traveler),
++ SND_MOTU_DEV_ENTRY(0x000015, &motu_828mk3), /* FireWire only. */
++ SND_MOTU_DEV_ENTRY(0x000035, &motu_828mk3), /* Hybrid. */
++ SND_MOTU_DEV_ENTRY(0x000033, &motu_audio_express),
+ { }
+ };
+ MODULE_DEVICE_TABLE(ieee1394, motu_id_table);
--- /dev/null
+From 721f1e6c1fd137e7e2053d8e103b666faaa2d50c Mon Sep 17 00:00:00 2001
+From: Jaroslav Kysela <perex@perex.cz>
+Date: Mon, 18 Mar 2019 13:45:43 +0100
+Subject: ALSA: hda - add Lenovo IdeaCentre B550 to the power_save_blacklist
+
+From: Jaroslav Kysela <perex@perex.cz>
+
+commit 721f1e6c1fd137e7e2053d8e103b666faaa2d50c upstream.
+
+Another machine which does not like the power saving (noise):
+ https://bugzilla.redhat.com/show_bug.cgi?id=1689623
+
+Also, reorder the Lenovo C50 entry to keep the table sorted.
+
+Reported-by: hs.guimaraes@outlook.com
+Signed-off-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_intel.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -2144,10 +2144,12 @@ static struct snd_pci_quirk power_save_b
+ SND_PCI_QUIRK(0x8086, 0x2057, "Intel NUC5i7RYB", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1520902 */
+ SND_PCI_QUIRK(0x8086, 0x2068, "Intel NUC7i3BNB", 0),
+- /* https://bugzilla.redhat.com/show_bug.cgi?id=1572975 */
+- SND_PCI_QUIRK(0x17aa, 0x36a7, "Lenovo C50 All in one", 0),
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
+ SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
++ /* https://bugzilla.redhat.com/show_bug.cgi?id=1689623 */
++ SND_PCI_QUIRK(0x17aa, 0x367b, "Lenovo IdeaCentre B550", 0),
++ /* https://bugzilla.redhat.com/show_bug.cgi?id=1572975 */
++ SND_PCI_QUIRK(0x17aa, 0x36a7, "Lenovo C50 All in one", 0),
+ {}
+ };
+ #endif /* CONFIG_PM */
--- /dev/null
+From 72464382fc2d3673eb51f21a57f2c0a320c1552f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Mon, 18 Mar 2019 11:09:54 +0100
+Subject: drm/amdgpu: fix invalid use of change_bit
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit 72464382fc2d3673eb51f21a57f2c0a320c1552f upstream.
+
+We only need to clear the bit in a 32bit integer.
+
+This fixes a crah on ARM64 and PPC64LE caused by
+"drm/amdgpu: update the vm invalidation engine layout V2"
+
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+@@ -738,7 +738,7 @@ static int gmc_v9_0_allocate_vm_inv_eng(
+ }
+
+ ring->vm_inv_eng = inv_eng - 1;
+- change_bit(inv_eng - 1, (unsigned long *)(&vm_inv_engs[vmhub]));
++ vm_inv_engs[vmhub] &= ~(1 << ring->vm_inv_eng);
+
+ dev_info(adev->dev, "ring %s uses VM inv eng %u on hub %u\n",
+ ring->name, ring->vm_inv_eng, ring->funcs->vmhub);
--- /dev/null
+From c2d311553855395764e2e5bf401d987ba65c2056 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Mon, 18 Mar 2019 15:47:58 +0100
+Subject: drm/vmwgfx: Don't double-free the mode stored in par->set_mode
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit c2d311553855395764e2e5bf401d987ba65c2056 upstream.
+
+When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
+twice. The first free is in vmw_fb_kms_detach(), the second is near the
+end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
+only works correctly if the mode doesn't actually change. Removing
+'old_mode' in favor of using par->set_mode directly fixes the problem.
+
+Cc: <stable@vger.kernel.org>
+Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reviewed-by: Deepak Rawat <drawat@vmware.com>
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++---------
+ 1 file changed, 3 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+@@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
+ };
+- struct drm_display_mode *old_mode;
+ struct drm_display_mode *mode;
+ int ret;
+
+- old_mode = par->set_mode;
+ mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
+ if (!mode) {
+ DRM_ERROR("Could not create new fb mode.\n");
+@@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info
+ mode->vdisplay = var->yres;
+ vmw_guess_mode_timing(mode);
+
+- if (old_mode && drm_mode_equal(old_mode, mode)) {
+- drm_mode_destroy(vmw_priv->dev, mode);
+- mode = old_mode;
+- old_mode = NULL;
+- } else if (!vmw_kms_validate_mode_vram(vmw_priv,
++ if (!vmw_kms_validate_mode_vram(vmw_priv,
+ mode->hdisplay *
+ DIV_ROUND_UP(var->bits_per_pixel, 8),
+ mode->vdisplay)) {
+@@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info
+ schedule_delayed_work(&par->local_work, 0);
+
+ out_unlock:
+- if (old_mode)
+- drm_mode_destroy(vmw_priv->dev, old_mode);
++ if (par->set_mode)
++ drm_mode_destroy(vmw_priv->dev, par->set_mode);
+ par->set_mode = mode;
+
+ mutex_unlock(&par->bo_mutex);
--- /dev/null
+From 4b9ce3a651a37c60527101db4451a315a8b9588f Mon Sep 17 00:00:00 2001
+From: Deepak Rawat <drawat@vmware.com>
+Date: Thu, 28 Feb 2019 10:29:54 -0800
+Subject: drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's
+
+From: Deepak Rawat <drawat@vmware.com>
+
+commit 4b9ce3a651a37c60527101db4451a315a8b9588f upstream.
+
+If it's not a system error and get_node implementation accommodate the
+buffer object then it should return 0 with memm::mm_node set to NULL.
+
+v2: Test for id != -ENOMEM instead of id == -ENOSPC.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API")
+Signed-off-by: Deepak Rawat <drawat@vmware.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+@@ -57,7 +57,7 @@ static int vmw_gmrid_man_get_node(struct
+
+ id = ida_alloc_max(&gman->gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id < 0)
+- return id;
++ return (id != -ENOMEM ? 0 : id);
+
+ spin_lock(&gman->lock);
+
--- /dev/null
+From 4e50ce03976fbc8ae995a000c4b10c737467beaa Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Wed, 13 Mar 2019 10:03:17 +0100
+Subject: iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.
+
+Take into account that sg->offset can be bigger than PAGE_SIZE when
+setting segment sg->dma_address. Otherwise sg->dma_address will point
+at diffrent page, what makes DMA not possible with erros like this:
+
+xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
+xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
+xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
+xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
+xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]
+
+Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
+what what can cause crashes like this:
+
+Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon pfn:39e8b1
+Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
+Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
+Feb 28 19:27:45 kernel: raw: 02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
+Feb 28 19:27:45 kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
+Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
+Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
+Feb 28 19:27:45 kernel: scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
+Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G B W E 4.20.12-arch1-1-custom #1
+Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
+Feb 28 19:27:45 kernel: Call Trace:
+Feb 28 19:27:45 kernel: dump_stack+0x5c/0x80
+Feb 28 19:27:45 kernel: bad_page.cold.29+0x7f/0xb2
+Feb 28 19:27:45 kernel: __free_pages_ok+0x2c0/0x2d0
+Feb 28 19:27:45 kernel: skb_release_data+0x96/0x180
+Feb 28 19:27:45 kernel: __kfree_skb+0xe/0x20
+Feb 28 19:27:45 kernel: tcp_recvmsg+0x894/0xc60
+Feb 28 19:27:45 kernel: ? reuse_swap_page+0x120/0x340
+Feb 28 19:27:45 kernel: ? ptep_set_access_flags+0x23/0x30
+Feb 28 19:27:45 kernel: inet_recvmsg+0x5b/0x100
+Feb 28 19:27:45 kernel: __sys_recvfrom+0xc3/0x180
+Feb 28 19:27:45 kernel: ? handle_mm_fault+0x10a/0x250
+Feb 28 19:27:45 kernel: ? syscall_trace_enter+0x1d3/0x2d0
+Feb 28 19:27:45 kernel: ? __audit_syscall_exit+0x22a/0x290
+Feb 28 19:27:45 kernel: __x64_sys_recvfrom+0x24/0x30
+Feb 28 19:27:45 kernel: do_syscall_64+0x5b/0x170
+Feb 28 19:27:45 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+Cc: stable@vger.kernel.org
+Reported-and-tested-by: Jan Viktorin <jan.viktorin@gmail.com>
+Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Fixes: 80187fd39dcb ('iommu/amd: Optimize map_sg and unmap_sg')
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/amd_iommu.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/iommu/amd_iommu.c
++++ b/drivers/iommu/amd_iommu.c
+@@ -2605,7 +2605,12 @@ static int map_sg(struct device *dev, st
+
+ /* Everything is mapped - write the right values into s->dma_address */
+ for_each_sg(sglist, s, nelems, i) {
+- s->dma_address += address + s->offset;
++ /*
++ * Add in the remaining piece of the scatter-gather offset that
++ * was masked out when we were determining the physical address
++ * via (sg_phys(s) & PAGE_MASK) earlier.
++ */
++ s->dma_address += address + (s->offset & ~PAGE_MASK);
+ s->dma_length = s->length;
+ }
+
--- /dev/null
+From 80ef4464d5e27408685e609d389663aad46644b9 Mon Sep 17 00:00:00 2001
+From: Robert Richter <rrichter@marvell.com>
+Date: Wed, 20 Mar 2019 18:57:23 +0000
+Subject: iommu/iova: Fix tracking of recently failed iova address
+
+From: Robert Richter <rrichter@marvell.com>
+
+commit 80ef4464d5e27408685e609d389663aad46644b9 upstream.
+
+If a 32 bit allocation request is too big to possibly succeed, it
+early exits with a failure and then should never update max32_alloc_
+size. This patch fixes current code, now the size is only updated if
+the slow path failed while walking the tree. Without the fix the
+allocation may enter the slow path again even if there was a failure
+before of a request with the same or a smaller size.
+
+Cc: <stable@vger.kernel.org> # 4.20+
+Fixes: bee60e94a1e2 ("iommu/iova: Optimise attempts to allocate iova from 32bit address range")
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Robert Richter <rrichter@marvell.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/iova.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/iova.c
++++ b/drivers/iommu/iova.c
+@@ -207,8 +207,10 @@ static int __alloc_and_insert_iova_range
+ curr_iova = rb_entry(curr, struct iova, node);
+ } while (curr && new_pfn <= curr_iova->pfn_hi);
+
+- if (limit_pfn < size || new_pfn < iovad->start_pfn)
++ if (limit_pfn < size || new_pfn < iovad->start_pfn) {
++ iovad->max32_alloc_size = size;
+ goto iova32_full;
++ }
+
+ /* pfn_lo will point to size aligned address if size_aligned is set */
+ new->pfn_lo = new_pfn;
+@@ -222,7 +224,6 @@ static int __alloc_and_insert_iova_range
+ return 0;
+
+ iova32_full:
+- iovad->max32_alloc_size = size;
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return -ENOMEM;
+ }
--- /dev/null
+From bb229bbb3bf63d23128e851a1f3b85c083178fa1 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Wed, 20 Mar 2019 09:46:58 +0100
+Subject: libceph: wait for latest osdmap in ceph_monc_blacklist_add()
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream.
+
+Because map updates are distributed lazily, an OSD may not know about
+the new blacklist for quite some time after "osd blacklist add" command
+is completed. This makes it possible for a blacklisted but still alive
+client to overwrite a post-blacklist update, resulting in data
+corruption.
+
+Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
+the post-blacklist epoch for all post-blacklist requests ensures that
+all such requests "wait" for the blacklist to come into force on their
+respective OSDs.
+
+Cc: stable@vger.kernel.org
+Fixes: 6305a3b41515 ("libceph: support for blacklisting clients")
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Jason Dillaman <dillaman@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/ceph/libceph.h | 2 ++
+ net/ceph/ceph_common.c | 18 +++++++++++++++++-
+ net/ceph/mon_client.c | 9 +++++++++
+ 3 files changed, 28 insertions(+), 1 deletion(-)
+
+--- a/include/linux/ceph/libceph.h
++++ b/include/linux/ceph/libceph.h
+@@ -294,6 +294,8 @@ extern void ceph_destroy_client(struct c
+ extern int __ceph_open_session(struct ceph_client *client,
+ unsigned long started);
+ extern int ceph_open_session(struct ceph_client *client);
++int ceph_wait_for_latest_osdmap(struct ceph_client *client,
++ unsigned long timeout);
+
+ /* pagevec.c */
+ extern void ceph_release_page_vector(struct page **pages, int num_pages);
+--- a/net/ceph/ceph_common.c
++++ b/net/ceph/ceph_common.c
+@@ -738,7 +738,6 @@ int __ceph_open_session(struct ceph_clie
+ }
+ EXPORT_SYMBOL(__ceph_open_session);
+
+-
+ int ceph_open_session(struct ceph_client *client)
+ {
+ int ret;
+@@ -754,6 +753,23 @@ int ceph_open_session(struct ceph_client
+ }
+ EXPORT_SYMBOL(ceph_open_session);
+
++int ceph_wait_for_latest_osdmap(struct ceph_client *client,
++ unsigned long timeout)
++{
++ u64 newest_epoch;
++ int ret;
++
++ ret = ceph_monc_get_version(&client->monc, "osdmap", &newest_epoch);
++ if (ret)
++ return ret;
++
++ if (client->osdc.osdmap->epoch >= newest_epoch)
++ return 0;
++
++ ceph_osdc_maybe_request_map(&client->osdc);
++ return ceph_monc_wait_osdmap(&client->monc, newest_epoch, timeout);
++}
++EXPORT_SYMBOL(ceph_wait_for_latest_osdmap);
+
+ static int __init init_ceph_lib(void)
+ {
+--- a/net/ceph/mon_client.c
++++ b/net/ceph/mon_client.c
+@@ -922,6 +922,15 @@ int ceph_monc_blacklist_add(struct ceph_
+ mutex_unlock(&monc->mutex);
+
+ ret = wait_generic_request(req);
++ if (!ret)
++ /*
++ * Make sure we have the osdmap that includes the blacklist
++ * entry. This is needed to ensure that the OSDs pick up the
++ * new blacklist before processing any future requests from
++ * this client.
++ */
++ ret = ceph_wait_for_latest_osdmap(monc->client, 0);
++
+ out:
+ put_generic_request(req);
+ return ret;
--- /dev/null
+From 3f0a53bc6482fb09770982a8447981260ea258dc Mon Sep 17 00:00:00 2001
+From: Yasha Cherikovsky <yasha.che3@gmail.com>
+Date: Fri, 8 Mar 2019 14:58:51 +0200
+Subject: MIPS: Ensure ELF appended dtb is relocated
+
+From: Yasha Cherikovsky <yasha.che3@gmail.com>
+
+commit 3f0a53bc6482fb09770982a8447981260ea258dc upstream.
+
+This fixes booting with the combination of CONFIG_RELOCATABLE=y
+and CONFIG_MIPS_ELF_APPENDED_DTB=y.
+
+Sections that appear after the relocation table are not relocated
+on system boot (except .bss, which has special handling).
+
+With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
+vmlinux ELF, so it must be relocated together with everything else.
+
+Fixes: 069fd766271d ("MIPS: Reserve space for relocation table")
+Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Paul Burton <paul.burton@mips.com>
+Cc: James Hogan <jhogan@kernel.org>
+Cc: linux-mips@linux-mips.org
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org # v4.7+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/kernel/vmlinux.lds.S | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/arch/mips/kernel/vmlinux.lds.S
++++ b/arch/mips/kernel/vmlinux.lds.S
+@@ -140,6 +140,13 @@ SECTIONS
+ PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
+ #endif
+
++#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
++ .appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
++ *(.appended_dtb)
++ KEEP(*(.appended_dtb))
++ }
++#endif
++
+ #ifdef CONFIG_RELOCATABLE
+ . = ALIGN(4);
+
+@@ -164,11 +171,6 @@ SECTIONS
+ __appended_dtb = .;
+ /* leave space for appended DTB */
+ . += 0x100000;
+-#elif defined(CONFIG_MIPS_ELF_APPENDED_DTB)
+- .appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
+- *(.appended_dtb)
+- KEEP(*(.appended_dtb))
+- }
+ #endif
+ /*
+ * Align to 64K in attempt to eliminate holes before the
--- /dev/null
+From 47c25036b60f27b86ab44b66a8861bcf81cde39b Mon Sep 17 00:00:00 2001
+From: Archer Yan <ayan@wavecomp.com>
+Date: Fri, 8 Mar 2019 03:29:19 +0000
+Subject: MIPS: Fix kernel crash for R6 in jump label branch function
+
+From: Archer Yan <ayan@wavecomp.com>
+
+commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
+
+Insert Branch instruction instead of NOP to make sure assembler don't
+patch code in forbidden slot. In jump label function, it might
+be possible to patch Control Transfer Instructions(CTIs) into
+forbidden slot, which will generate Reserved Instruction exception
+in MIPS release 6.
+
+Signed-off-by: Archer Yan <ayan@wavecomp.com>
+Reviewed-by: Paul Burton <paul.burton@mips.com>
+[paul.burton@mips.com:
+ - Add MIPS prefix to subject.
+ - Mark for stable from v4.0, which introduced r6 support, onwards.]
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: linux-mips@vger.kernel.org
+Cc: stable@vger.kernel.org # v4.0+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/include/asm/jump_label.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/mips/include/asm/jump_label.h
++++ b/arch/mips/include/asm/jump_label.h
+@@ -21,15 +21,15 @@
+ #endif
+
+ #ifdef CONFIG_CPU_MICROMIPS
+-#define NOP_INSN "nop32"
++#define B_INSN "b32"
+ #else
+-#define NOP_INSN "nop"
++#define B_INSN "b"
+ #endif
+
+ static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
+ {
+- asm_volatile_goto("1:\t" NOP_INSN "\n\t"
+- "nop\n\t"
++ asm_volatile_goto("1:\t" B_INSN " 2f\n\t"
++ "2:\tnop\n\t"
+ ".pushsection __jump_table, \"aw\"\n\t"
+ WORD_INSN " 1b, %l[l_yes], %0\n\t"
+ ".popsection\n\t"
--- /dev/null
+From 5f5f67da9781770df0403269bc57d7aae608fecd Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Tue, 5 Mar 2019 06:00:22 +0800
+Subject: mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream.
+
+Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
+triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
+cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
+and the machine would be unable to resume once suspended.
+
+Previously, MIPS IRQs were not disabled properly, so the original
+code appeared to work. Commit a3e6c1eff5 ("MIPS: IRQ: Fix disable_irq on
+CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
+cascade_irqaction.
+
+This commit is functionally identical to 0add9c2f1cff ("MIPS:
+Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
+to apply the same fix to Loongson2.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: linux-mips@vger.kernel.org
+Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Cc: Huacai Chen <chenhc@lemote.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: James Hogan <jhogan@kernel.org>
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org # v3.19+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/loongson64/lemote-2f/irq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/loongson64/lemote-2f/irq.c
++++ b/arch/mips/loongson64/lemote-2f/irq.c
+@@ -103,7 +103,7 @@ static struct irqaction ip6_irqaction =
+ static struct irqaction cascade_irqaction = {
+ .handler = no_action,
+ .name = "cascade",
+- .flags = IRQF_NO_THREAD,
++ .flags = IRQF_NO_THREAD | IRQF_NO_SUSPEND,
+ };
+
+ void __init mach_init_irq(void)
--- /dev/null
+From 5ea47691bd99e1100707ec63364aff72324e2af4 Mon Sep 17 00:00:00 2001
+From: Daniel Drake <drake@endlessm.com>
+Date: Wed, 20 Mar 2019 14:36:53 +0800
+Subject: mmc: alcor: fix DMA reads
+
+From: Daniel Drake <drake@endlessm.com>
+
+commit 5ea47691bd99e1100707ec63364aff72324e2af4 upstream.
+
+Setting max_blk_count to 1 here was causing the mmc block layer
+to always use the MMC_READ_SINGLE_BLOCK command here, which the
+driver does not DMA-accelerate.
+
+Drop the max_blk_ settings here. The mmc host defaults suffice,
+along with the max_segs and max_seg_size settings, which I have
+now documented in more detail.
+
+Now each MMC command reads 4 512-byte blocks, using DMA instead of
+PIO. On my SD card, this increases read performance (measured with dd)
+from 167kb/sec to 4.6mb/sec.
+
+Link: http://lkml.kernel.org/r/CAD8Lp47L5T3jnAjBiPs1cQ+yFA3L6LJtgFvMETnBrY63-Zdi2g@mail.gmail.com
+Signed-off-by: Daniel Drake <drake@endlessm.com>
+Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
+Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/alcor.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/drivers/mmc/host/alcor.c
++++ b/drivers/mmc/host/alcor.c
+@@ -1044,14 +1044,27 @@ static void alcor_init_mmc(struct alcor_
+ mmc->caps2 = MMC_CAP2_NO_SDIO;
+ mmc->ops = &alcor_sdc_ops;
+
+- /* Hardware cannot do scatter lists */
++ /* The hardware does DMA data transfer of 4096 bytes to/from a single
++ * buffer address. Scatterlists are not supported, but upon DMA
++ * completion (signalled via IRQ), the original vendor driver does
++ * then immediately set up another DMA transfer of the next 4096
++ * bytes.
++ *
++ * This means that we need to handle the I/O in 4096 byte chunks.
++ * Lacking a way to limit the sglist entries to 4096 bytes, we instead
++ * impose that only one segment is provided, with maximum size 4096,
++ * which also happens to be the minimum size. This means that the
++ * single-entry sglist handled by this driver can be handed directly
++ * to the hardware, nice and simple.
++ *
++ * Unfortunately though, that means we only do 4096 bytes I/O per
++ * MMC command. A future improvement would be to make the driver
++ * accept sg lists and entries of any size, and simply iterate
++ * through them 4096 bytes at a time.
++ */
+ mmc->max_segs = AU6601_MAX_DMA_SEGMENTS;
+ mmc->max_seg_size = AU6601_MAX_DMA_BLOCK_SIZE;
+-
+- mmc->max_blk_size = mmc->max_seg_size;
+- mmc->max_blk_count = mmc->max_segs;
+-
+- mmc->max_req_size = mmc->max_seg_size * mmc->max_segs;
++ mmc->max_req_size = mmc->max_seg_size;
+ }
+
+ static int alcor_pci_sdmmc_drv_probe(struct platform_device *pdev)
--- /dev/null
+From 2b77158ffa92b820a0c5da9a3c6ead7aa069c71c Mon Sep 17 00:00:00 2001
+From: Alexander Shiyan <shc_work@mail.ru>
+Date: Sun, 17 Mar 2019 12:58:25 +0300
+Subject: mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages"
+
+From: Alexander Shiyan <shc_work@mail.ru>
+
+commit 2b77158ffa92b820a0c5da9a3c6ead7aa069c71c upstream.
+
+This reverts commit b189e7589f6d3411e85c6b7ae6eef158f08f388f.
+
+Unable to handle kernel paging request at virtual address c8358000
+pgd = efa405c3
+[c8358000] *pgd=00000000
+Internal error: Oops: 805 [#1] PREEMPT ARM
+CPU: 0 PID: 711 Comm: kworker/0:2 Not tainted 4.20.0+ #30
+Hardware name: Freescale i.MX27 (Device Tree Support)
+Workqueue: events mxcmci_datawork
+PC is at mxcmci_datawork+0xbc/0x2ac
+LR is at mxcmci_datawork+0xac/0x2ac
+pc : [<c04e33c8>] lr : [<c04e33b8>] psr: 60000013
+sp : c6c93f08 ip : 24004180 fp : 00000008
+r10: c8358000 r9 : c78b3e24 r8 : c6c92000
+r7 : 00000000 r6 : c7bb8680 r5 : c7bb86d4 r4 : c78b3de0
+r3 : 00002502 r2 : c090b2e0 r1 : 00000880 r0 : 00000000
+Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
+Control: 0005317f Table: a68a8000 DAC: 00000055
+Process kworker/0:2 (pid: 711, stack limit = 0x389543bc)
+Stack: (0xc6c93f08 to 0xc6c94000)
+3f00: c7bb86d4 00000000 00000000 c6cbfde0 c7bb86d4 c7ee4200
+3f20: 00000000 c0907ea8 00000000 c7bb86d8 c0907ea8 c012077c c6cbfde0 c7bb86d4
+3f40: c6cbfde0 c6c92000 c6cbfdf4 c09280ba c0907ea8 c090b2e0 c0907ebc c0120c18
+3f60: c6cbfde0 00000000 00000000 c6cbb580 c7ba7c40 c7837edc c6cbb598 00000000
+3f80: c6cbfde0 c01208f8 00000000 c01254fc c7ba7c40 c0125400 00000000 00000000
+3fa0: 00000000 00000000 00000000 c01010d0 00000000 00000000 00000000 00000000
+3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
+[<c04e33c8>] (mxcmci_datawork) from [<c012077c>] (process_one_work+0x1f0/0x338)
+[<c012077c>] (process_one_work) from [<c0120c18>] (worker_thread+0x320/0x474)
+[<c0120c18>] (worker_thread) from [<c01254fc>] (kthread+0xfc/0x118)
+[<c01254fc>] (kthread) from [<c01010d0>] (ret_from_fork+0x14/0x24)
+Exception stack(0xc6c93fb0 to 0xc6c93ff8)
+3fa0: 00000000 00000000 00000000 00000000
+3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
+Code: e3500000 1a000059 e5153050 e5933038 (e48a3004)
+---[ end trace 54ca629b75f0e737 ]---
+note: kworker/0:2[711] exited with preempt_count 1
+
+Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
+Fixes: b189e7589f6d ("mmc: mxcmmc: handle highmem pages")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/mxcmmc.c | 16 ++++------------
+ 1 file changed, 4 insertions(+), 12 deletions(-)
+
+--- a/drivers/mmc/host/mxcmmc.c
++++ b/drivers/mmc/host/mxcmmc.c
+@@ -292,11 +292,8 @@ static void mxcmci_swap_buffers(struct m
+ struct scatterlist *sg;
+ int i;
+
+- for_each_sg(data->sg, sg, data->sg_len, i) {
+- void *buf = kmap_atomic(sg_page(sg) + sg->offset);
+- buffer_swap32(buf, sg->length);
+- kunmap_atomic(buf);
+- }
++ for_each_sg(data->sg, sg, data->sg_len, i)
++ buffer_swap32(sg_virt(sg), sg->length);
+ }
+ #else
+ static inline void mxcmci_swap_buffers(struct mmc_data *data) {}
+@@ -613,7 +610,6 @@ static int mxcmci_transfer_data(struct m
+ {
+ struct mmc_data *data = host->req->data;
+ struct scatterlist *sg;
+- void *buf;
+ int stat, i;
+
+ host->data = data;
+@@ -621,18 +617,14 @@ static int mxcmci_transfer_data(struct m
+
+ if (data->flags & MMC_DATA_READ) {
+ for_each_sg(data->sg, sg, data->sg_len, i) {
+- buf = kmap_atomic(sg_page(sg) + sg->offset);
+- stat = mxcmci_pull(host, buf, sg->length);
+- kunmap(buf);
++ stat = mxcmci_pull(host, sg_virt(sg), sg->length);
+ if (stat)
+ return stat;
+ host->datasize += sg->length;
+ }
+ } else {
+ for_each_sg(data->sg, sg, data->sg_len, i) {
+- buf = kmap_atomic(sg_page(sg) + sg->offset);
+- stat = mxcmci_push(host, buf, sg->length);
+- kunmap(buf);
++ stat = mxcmci_push(host, sg_virt(sg), sg->length);
+ if (stat)
+ return stat;
+ host->datasize += sg->length;
--- /dev/null
+From e60a582bcde01158a64ff948fb799f21f5d31a11 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 7 Mar 2019 11:09:19 +0100
+Subject: mmc: pxamci: fix enum type confusion
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit e60a582bcde01158a64ff948fb799f21f5d31a11 upstream.
+
+clang points out several instances of mismatched types in this drivers,
+all coming from a single declaration:
+
+drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
+ different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
+ direction = DMA_DEV_TO_MEM;
+ ~ ^~~~~~~~~~~~~~
+drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
+ different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
+ tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,
+
+The behavior is correct, so this must be a simply typo from
+dma_data_direction and dma_transfer_direction being similarly named
+types with a similar purpose.
+
+Fixes: 6464b7140951 ("mmc: pxamci: switch over to dmaengine use")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/pxamci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/pxamci.c
++++ b/drivers/mmc/host/pxamci.c
+@@ -162,7 +162,7 @@ static void pxamci_dma_irq(void *param);
+ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)
+ {
+ struct dma_async_tx_descriptor *tx;
+- enum dma_data_direction direction;
++ enum dma_transfer_direction direction;
+ struct dma_slave_config config;
+ struct dma_chan *chan;
+ unsigned int nob = data->blocks;
--- /dev/null
+From c9a9497ccef205ed4ed2e247011382627876d831 Mon Sep 17 00:00:00 2001
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Date: Tue, 19 Mar 2019 11:12:59 +0100
+Subject: mmc: renesas_sdhi: limit block count to 16 bit for old revisions
+
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+commit c9a9497ccef205ed4ed2e247011382627876d831 upstream.
+
+R-Car Gen2 has two different SDHI incarnations in the same chip. The
+older one does not support the recently introduced 32 bit register
+access to the block count register. Make sure we use this feature only
+after the first known version.
+
+Thanks to the Renesas Testing team for this bug report!
+
+Fixes: 5603731a15ef ("mmc: tmio: fix access width of Block Count Register")
+Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Tested-by: Phong Hoang <phong.hoang.wz@renesas.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/renesas_sdhi_core.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/renesas_sdhi_core.c
++++ b/drivers/mmc/host/renesas_sdhi_core.c
+@@ -634,6 +634,7 @@ int renesas_sdhi_probe(struct platform_d
+ struct renesas_sdhi *priv;
+ struct resource *res;
+ int irq, ret, i;
++ u16 ver;
+
+ of_data = of_device_get_match_data(&pdev->dev);
+
+@@ -766,12 +767,17 @@ int renesas_sdhi_probe(struct platform_d
+ if (ret)
+ goto efree;
+
++ ver = sd_ctrl_read16(host, CTL_VERSION);
++ /* GEN2_SDR104 is first known SDHI to use 32bit block count */
++ if (ver < SDHI_VER_GEN2_SDR104 && mmc_data->max_blk_count > U16_MAX)
++ mmc_data->max_blk_count = U16_MAX;
++
+ ret = tmio_mmc_host_probe(host);
+ if (ret < 0)
+ goto edisclk;
+
+ /* One Gen2 SDHI incarnation does NOT have a CBSY bit */
+- if (sd_ctrl_read16(host, CTL_VERSION) == SDHI_VER_GEN2_SDR50)
++ if (ver == SDHI_VER_GEN2_SDR50)
+ mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY;
+
+ /* Enable tuning iff we have an SCC and a supported mode */
--- /dev/null
+From f84b66b9cce78e8f9d38204fdaa75f07c75f4911 Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+Date: Wed, 6 Mar 2019 19:20:50 +0200
+Subject: net/mlx5: Fix DCT creation bad flow
+
+From: Yishai Hadas <yishaih@mellanox.com>
+
+commit f84b66b9cce78e8f9d38204fdaa75f07c75f4911 upstream.
+
+In case the DCT creation command has succeeded a DRAIN must be issued
+before calling DESTROY.
+
+In addition, the original code used the wrong parameter for the DESTROY
+command, 'in' instead of 'din', which caused another creation try instead
+of destroying.
+
+Cc: <stable@vger.kernel.org> # 4.15
+Fixes: 57cda166bbe0 ("net/mlx5: Add DCT command interface")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/mellanox/mlx5/core/qp.c | 66 ++++++++++++++-------------
+ 1 file changed, 36 insertions(+), 30 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/qp.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
+@@ -40,6 +40,9 @@
+ #include "mlx5_core.h"
+ #include "lib/eq.h"
+
++static int mlx5_core_drain_dct(struct mlx5_core_dev *dev,
++ struct mlx5_core_dct *dct);
++
+ static struct mlx5_core_rsc_common *
+ mlx5_get_rsc(struct mlx5_qp_table *table, u32 rsn)
+ {
+@@ -227,13 +230,42 @@ static void destroy_resource_common(stru
+ wait_for_completion(&qp->common.free);
+ }
+
++static int _mlx5_core_destroy_dct(struct mlx5_core_dev *dev,
++ struct mlx5_core_dct *dct, bool need_cleanup)
++{
++ u32 out[MLX5_ST_SZ_DW(destroy_dct_out)] = {0};
++ u32 in[MLX5_ST_SZ_DW(destroy_dct_in)] = {0};
++ struct mlx5_core_qp *qp = &dct->mqp;
++ int err;
++
++ err = mlx5_core_drain_dct(dev, dct);
++ if (err) {
++ if (dev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) {
++ goto destroy;
++ } else {
++ mlx5_core_warn(
++ dev, "failed drain DCT 0x%x with error 0x%x\n",
++ qp->qpn, err);
++ return err;
++ }
++ }
++ wait_for_completion(&dct->drained);
++destroy:
++ if (need_cleanup)
++ destroy_resource_common(dev, &dct->mqp);
++ MLX5_SET(destroy_dct_in, in, opcode, MLX5_CMD_OP_DESTROY_DCT);
++ MLX5_SET(destroy_dct_in, in, dctn, qp->qpn);
++ MLX5_SET(destroy_dct_in, in, uid, qp->uid);
++ err = mlx5_cmd_exec(dev, (void *)&in, sizeof(in),
++ (void *)&out, sizeof(out));
++ return err;
++}
++
+ int mlx5_core_create_dct(struct mlx5_core_dev *dev,
+ struct mlx5_core_dct *dct,
+ u32 *in, int inlen)
+ {
+ u32 out[MLX5_ST_SZ_DW(create_dct_out)] = {0};
+- u32 din[MLX5_ST_SZ_DW(destroy_dct_in)] = {0};
+- u32 dout[MLX5_ST_SZ_DW(destroy_dct_out)] = {0};
+ struct mlx5_core_qp *qp = &dct->mqp;
+ int err;
+
+@@ -254,11 +286,7 @@ int mlx5_core_create_dct(struct mlx5_cor
+
+ return 0;
+ err_cmd:
+- MLX5_SET(destroy_dct_in, din, opcode, MLX5_CMD_OP_DESTROY_DCT);
+- MLX5_SET(destroy_dct_in, din, dctn, qp->qpn);
+- MLX5_SET(destroy_dct_in, din, uid, qp->uid);
+- mlx5_cmd_exec(dev, (void *)&in, sizeof(din),
+- (void *)&out, sizeof(dout));
++ _mlx5_core_destroy_dct(dev, dct, false);
+ return err;
+ }
+ EXPORT_SYMBOL_GPL(mlx5_core_create_dct);
+@@ -323,29 +351,7 @@ static int mlx5_core_drain_dct(struct ml
+ int mlx5_core_destroy_dct(struct mlx5_core_dev *dev,
+ struct mlx5_core_dct *dct)
+ {
+- u32 out[MLX5_ST_SZ_DW(destroy_dct_out)] = {0};
+- u32 in[MLX5_ST_SZ_DW(destroy_dct_in)] = {0};
+- struct mlx5_core_qp *qp = &dct->mqp;
+- int err;
+-
+- err = mlx5_core_drain_dct(dev, dct);
+- if (err) {
+- if (dev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) {
+- goto destroy;
+- } else {
+- mlx5_core_warn(dev, "failed drain DCT 0x%x with error 0x%x\n", qp->qpn, err);
+- return err;
+- }
+- }
+- wait_for_completion(&dct->drained);
+-destroy:
+- destroy_resource_common(dev, &dct->mqp);
+- MLX5_SET(destroy_dct_in, in, opcode, MLX5_CMD_OP_DESTROY_DCT);
+- MLX5_SET(destroy_dct_in, in, dctn, qp->qpn);
+- MLX5_SET(destroy_dct_in, in, uid, qp->uid);
+- err = mlx5_cmd_exec(dev, (void *)&in, sizeof(in),
+- (void *)&out, sizeof(out));
+- return err;
++ return _mlx5_core_destroy_dct(dev, dct, true);
+ }
+ EXPORT_SYMBOL_GPL(mlx5_core_destroy_dct);
+
--- /dev/null
+From 8bc086899816214fbc6047c9c7e15fcab49552bf Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 17 Mar 2019 01:17:56 +0000
+Subject: powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+commit 8bc086899816214fbc6047c9c7e15fcab49552bf upstream.
+
+MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
+enabled, and that was the case before commit 4ffe713b7587
+("powerpc/mm: Increase the max addressable memory to 2PB").
+
+On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
+define it as 46. That is larger than the real number of physical
+address bits, and breaks calculations in zsmalloc:
+
+ mm/zsmalloc.c:130:49: warning: right shift count is negative
+ MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
+ ^~
+ ...
+ mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file scope
+ struct size_class *size_class[ZS_SIZE_CLASSES];
+ ^~~~~~~~~~
+
+Fixes: 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to 2PB")
+Cc: stable@vger.kernel.org # v4.20+
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/mmu.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/include/asm/mmu.h
++++ b/arch/powerpc/include/asm/mmu.h
+@@ -341,7 +341,7 @@ static inline u16 get_mm_addr_key(struct
+ #if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME) && \
+ defined (CONFIG_PPC_64K_PAGES)
+ #define MAX_PHYSMEM_BITS 51
+-#else
++#elif defined(CONFIG_SPARSEMEM)
+ #define MAX_PHYSMEM_BITS 46
+ #endif
+
--- /dev/null
+From 92edf8df0ff2ae86cc632eeca0e651fd8431d40d Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Thu, 21 Mar 2019 15:24:33 +1100
+Subject: powerpc/security: Fix spectre_v2 reporting
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.
+
+When I updated the spectre_v2 reporting to handle software count cache
+flush I got the logic wrong when there's no software count cache
+enabled at all.
+
+The result is that on systems with the software count cache flush
+disabled we print:
+
+ Mitigation: Indirect branch cache disabled, Software count cache flush
+
+Which correctly indicates that the count cache is disabled, but
+incorrectly says the software count cache flush is enabled.
+
+The root of the problem is that we are trying to handle all
+combinations of options. But we know now that we only expect to see
+the software count cache flush enabled if the other options are false.
+
+So split the two cases, which simplifies the logic and fixes the bug.
+We were also missing a space before "(hardware accelerated)".
+
+The result is we see one of:
+
+ Mitigation: Indirect branch serialisation (kernel only)
+ Mitigation: Indirect branch cache disabled
+ Mitigation: Software count cache flush
+ Mitigation: Software count cache flush (hardware accelerated)
+
+Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Reviewed-by: Michael Neuling <mikey@neuling.org>
+Reviewed-by: Diana Craciun <diana.craciun@nxp.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/security.c | 23 ++++++++---------------
+ 1 file changed, 8 insertions(+), 15 deletions(-)
+
+--- a/arch/powerpc/kernel/security.c
++++ b/arch/powerpc/kernel/security.c
+@@ -190,29 +190,22 @@ ssize_t cpu_show_spectre_v2(struct devic
+ bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
+ ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
+
+- if (bcs || ccd || count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
+- bool comma = false;
++ if (bcs || ccd) {
+ seq_buf_printf(&s, "Mitigation: ");
+
+- if (bcs) {
++ if (bcs)
+ seq_buf_printf(&s, "Indirect branch serialisation (kernel only)");
+- comma = true;
+- }
+
+- if (ccd) {
+- if (comma)
+- seq_buf_printf(&s, ", ");
+- seq_buf_printf(&s, "Indirect branch cache disabled");
+- comma = true;
+- }
+-
+- if (comma)
++ if (bcs && ccd)
+ seq_buf_printf(&s, ", ");
+
+- seq_buf_printf(&s, "Software count cache flush");
++ if (ccd)
++ seq_buf_printf(&s, "Indirect branch cache disabled");
++ } else if (count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
++ seq_buf_printf(&s, "Mitigation: Software count cache flush");
+
+ if (count_cache_flush_type == COUNT_CACHE_FLUSH_HW)
+- seq_buf_printf(&s, "(hardware accelerated)");
++ seq_buf_printf(&s, " (hardware accelerated)");
+ } else if (btb_flush_enabled) {
+ seq_buf_printf(&s, "Mitigation: Branch predictor state flush");
+ } else {
--- /dev/null
+From b5b4453e7912f056da1ca7572574cada32ecb60c Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Thu, 14 Mar 2019 00:14:38 +1100
+Subject: powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+commit b5b4453e7912f056da1ca7572574cada32ecb60c upstream.
+
+Jakub Drnec reported:
+ Setting the realtime clock can sometimes make the monotonic clock go
+ back by over a hundred years. Decreasing the realtime clock across
+ the y2k38 threshold is one reliable way to reproduce. Allegedly this
+ can also happen just by running ntpd, I have not managed to
+ reproduce that other than booting with rtc at >2038 and then running
+ ntp. When this happens, anything with timers (e.g. openjdk) breaks
+ rather badly.
+
+And included a test case (slightly edited for brevity):
+ #define _POSIX_C_SOURCE 199309L
+ #include <stdio.h>
+ #include <time.h>
+ #include <stdlib.h>
+ #include <unistd.h>
+
+ long get_time(void) {
+ struct timespec tp;
+ clock_gettime(CLOCK_MONOTONIC, &tp);
+ return tp.tv_sec + tp.tv_nsec / 1000000000;
+ }
+
+ int main(void) {
+ long last = get_time();
+ while(1) {
+ long now = get_time();
+ if (now < last) {
+ printf("clock went backwards by %ld seconds!\n", last - now);
+ }
+ last = now;
+ sleep(1);
+ }
+ return 0;
+ }
+
+Which when run concurrently with:
+ # date -s 2040-1-1
+ # date -s 2037-1-1
+
+Will detect the clock going backward.
+
+The root cause is that wtom_clock_sec in struct vdso_data is only a
+32-bit signed value, even though we set its value to be equal to
+tk->wall_to_monotonic.tv_sec which is 64-bits.
+
+Because the monotonic clock starts at zero when the system boots the
+wall_to_montonic.tv_sec offset is negative for current and future
+dates. Currently on a freshly booted system the offset will be in the
+vicinity of negative 1.5 billion seconds.
+
+However if the wall clock is set past the Y2038 boundary, the offset
+from wall to monotonic becomes less than negative 2^31, and no longer
+fits in 32-bits. When that value is assigned to wtom_clock_sec it is
+truncated and becomes positive, causing the VDSO assembly code to
+calculate CLOCK_MONOTONIC incorrectly.
+
+That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
+it is not meant to do. Worse, if the time is then set back before the
+Y2038 boundary CLOCK_MONOTONIC will jump backward.
+
+We can fix it simply by storing the full 64-bit offset in the
+vdso_data, and using that in the VDSO assembly code. We also shuffle
+some of the fields in vdso_data to avoid creating a hole.
+
+The original commit that added the CLOCK_MONOTONIC support to the VDSO
+did actually use a 64-bit value for wtom_clock_sec, see commit
+a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to
+32 bits kernel") (Nov 2005). However just 3 days later it was
+converted to 32-bits in commit 0c37ec2aa88b ("[PATCH] powerpc: vdso
+fixes (take #2)"), and the bug has existed since then AFAICS.
+
+Fixes: 0c37ec2aa88b ("[PATCH] powerpc: vdso fixes (take #2)")
+Cc: stable@vger.kernel.org # v2.6.15+
+Link: http://lkml.kernel.org/r/HaC.ZfES.62bwlnvAvMP.1STMMj@seznam.cz
+Reported-by: Jakub Drnec <jaydee@email.cz>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/vdso_datapage.h | 8 ++++----
+ arch/powerpc/kernel/vdso64/gettimeofday.S | 4 ++--
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/arch/powerpc/include/asm/vdso_datapage.h
++++ b/arch/powerpc/include/asm/vdso_datapage.h
+@@ -82,10 +82,10 @@ struct vdso_data {
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
+- __s32 wtom_clock_sec; /* Wall to monotonic clock */
+- __s32 wtom_clock_nsec;
+- struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
+- __u32 stamp_sec_fraction; /* fractional seconds of stamp_xtime */
++ __u32 stamp_sec_fraction; /* fractional seconds of stamp_xtime */
++ __s32 wtom_clock_nsec; /* Wall to monotonic clock nsec */
++ __s64 wtom_clock_sec; /* Wall to monotonic clock sec */
++ struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
+ __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
+ __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
+ };
+--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
++++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
+@@ -92,7 +92,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
+ * At this point, r4,r5 contain our sec/nsec values.
+ */
+
+- lwa r6,WTOM_CLOCK_SEC(r3)
++ ld r6,WTOM_CLOCK_SEC(r3)
+ lwa r9,WTOM_CLOCK_NSEC(r3)
+
+ /* We now have our result in r6,r9. We create a fake dependency
+@@ -125,7 +125,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
+ bne cr6,75f
+
+ /* CLOCK_MONOTONIC_COARSE */
+- lwa r6,WTOM_CLOCK_SEC(r3)
++ ld r6,WTOM_CLOCK_SEC(r3)
+ lwa r9,WTOM_CLOCK_NSEC(r3)
+
+ /* check if counter has updated */
--- /dev/null
+From d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 11 Mar 2019 15:04:18 +0100
+Subject: udf: Fix crash on IO error during truncate
+
+From: Jan Kara <jack@suse.cz>
+
+commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream.
+
+When truncate(2) hits IO error when reading indirect extent block the
+code just bugs with:
+
+kernel BUG at linux-4.15.0/fs/udf/truncate.c:249!
+...
+
+Fix the problem by bailing out cleanly in case of IO error.
+
+CC: stable@vger.kernel.org
+Reported-by: jean-luc malet <jeanluc.malet@gmail.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/udf/truncate.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/udf/truncate.c
++++ b/fs/udf/truncate.c
+@@ -260,6 +260,9 @@ void udf_truncate_extents(struct inode *
+ epos.block = eloc;
+ epos.bh = udf_tread(sb,
+ udf_get_lb_pblock(sb, &eloc, 0));
++ /* Error reading indirect block? */
++ if (!epos.bh)
++ return;
+ if (elen)
+ indirect_ext_len =
+ (elen + sb->s_blocksize - 1) >>
projects / thirdparty / kernel / stable-queue.git / commitdiff
