--- /dev/null
+From 607975b30db41aad6edc846ed567191aa6b7d893 Mon Sep 17 00:00:00 2001
+From: Ding Xiang <dingxiang@cmss.chinamobile.com>
+Date: Tue, 23 Jul 2019 15:44:41 +0800
+Subject: ALSA: ac97: Fix double free of ac97_codec_device
+
+From: Ding Xiang <dingxiang@cmss.chinamobile.com>
+
+commit 607975b30db41aad6edc846ed567191aa6b7d893 upstream.
+
+put_device will call ac97_codec_release to free
+ac97_codec_device and other resources, so remove the kfree
+and other redundant code.
+
+Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus")
+Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/ac97/bus.c | 13 ++++---------
+ 1 file changed, 4 insertions(+), 9 deletions(-)
+
+--- a/sound/ac97/bus.c
++++ b/sound/ac97/bus.c
+@@ -122,17 +122,12 @@ static int ac97_codec_add(struct ac97_co
+ vendor_id);
+
+ ret = device_add(&codec->dev);
+- if (ret)
+- goto err_free_codec;
++ if (ret) {
++ put_device(&codec->dev);
++ return ret;
++ }
+
+ return 0;
+-err_free_codec:
+- of_node_put(codec->dev.of_node);
+- put_device(&codec->dev);
+- kfree(codec);
+- ac97_ctrl->codecs[idx] = NULL;
+-
+- return ret;
+ }
+
+ unsigned int snd_ac97_bus_scan_one(struct ac97_controller *adrv,
--- /dev/null
+From 3f8809499bf02ef7874254c5e23fc764a47a21a0 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Thu, 25 Jul 2019 14:57:37 +0800
+Subject: ALSA: hda - Add a conexant codec entry to let mute led work
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit 3f8809499bf02ef7874254c5e23fc764a47a21a0 upstream.
+
+This conexant codec isn't in the supported codec list yet, the hda
+generic driver can drive this codec well, but on a Lenovo machine
+with mute/mic-mute leds, we need to apply CXT_FIXUP_THINKPAD_ACPI
+to make the leds work. After adding this codec to the list, the
+driver patch_conexant.c will apply THINKPAD_ACPI to this machine.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_conexant.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -1083,6 +1083,7 @@ static int patch_conexant_auto(struct hd
+ */
+
+ static const struct hda_device_id snd_hda_id_conexant[] = {
++ HDA_CODEC_ENTRY(0x14f11f86, "CX8070", patch_conexant_auto),
+ HDA_CODEC_ENTRY(0x14f12008, "CX8200", patch_conexant_auto),
+ HDA_CODEC_ENTRY(0x14f15045, "CX20549 (Venice)", patch_conexant_auto),
+ HDA_CODEC_ENTRY(0x14f15047, "CX20551 (Waikiki)", patch_conexant_auto),
--- /dev/null
+From 2756d9143aa517b97961e85412882b8ce31371a6 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 19 Jul 2019 10:27:54 +0200
+Subject: ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2756d9143aa517b97961e85412882b8ce31371a6 upstream.
+
+It turned out that the recent Intel HD-audio controller chips show a
+significant stall during the system PM resume intermittently. It
+doesn't happen so often and usually it may read back successfully
+after one or more seconds, but in some rare worst cases the driver
+went into fallback mode.
+
+After trial-and-error, we found out that the communication stall seems
+covered by issuing the sync after each verb write, as already done for
+AMD and other chipsets. So this patch enables the write-sync flag for
+the recent Intel chips, Skylake and onward, as a workaround.
+
+Also, since Broxton and co have the very same driver flags as Skylake,
+refer to the Skylake driver flags instead of defining the same
+contents again for simplification.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901
+Reported-and-tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
+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 | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -313,11 +313,10 @@ enum {
+
+ #define AZX_DCAPS_INTEL_SKYLAKE \
+ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\
++ AZX_DCAPS_SYNC_WRITE |\
+ AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT)
+
+-#define AZX_DCAPS_INTEL_BROXTON \
+- (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\
+- AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT)
++#define AZX_DCAPS_INTEL_BROXTON AZX_DCAPS_INTEL_SKYLAKE
+
+ /* quirks for ATI SB / AMD Hudson */
+ #define AZX_DCAPS_PRESET_ATI_SB \
--- /dev/null
+From 70256b42caaf3e13c2932c2be7903a73fbe8bb8b Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Thu, 18 Jul 2019 17:53:13 +0800
+Subject: ALSA: line6: Fix wrong altsetting for LINE6_PODHD500_1
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 70256b42caaf3e13c2932c2be7903a73fbe8bb8b upstream.
+
+Commit 7b9584fa1c0b ("staging: line6: Move altsetting to properties")
+set a wrong altsetting for LINE6_PODHD500_1 during refactoring.
+
+Set the correct altsetting number to fix the issue.
+
+BugLink: https://bugs.launchpad.net/bugs/1790595
+Fixes: 7b9584fa1c0b ("staging: line6: Move altsetting to properties")
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/line6/podhd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/usb/line6/podhd.c
++++ b/sound/usb/line6/podhd.c
+@@ -413,7 +413,7 @@ static const struct line6_properties pod
+ .name = "POD HD500",
+ .capabilities = LINE6_CAP_PCM
+ | LINE6_CAP_HWMON,
+- .altsetting = 1,
++ .altsetting = 0,
+ .ep_ctrl_r = 0x81,
+ .ep_ctrl_w = 0x01,
+ .ep_audio_r = 0x86,
--- /dev/null
+From 0e279dcea0ec897af1c979ebee4ec92b461793f5 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 19 Jul 2019 10:55:05 +0200
+Subject: ALSA: pcm: Fix refcount_inc() on zero usage
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 0e279dcea0ec897af1c979ebee4ec92b461793f5 upstream.
+
+The recent rewrite of PCM link lock management introduced the refcount
+in snd_pcm_group object, managed by the kernel refcount_t API. This
+caused unexpected kernel warnings when the kernel is built with
+CONFIG_REFCOUNT_FULL=y. As the warning line indicates, the problem is
+obviously that we start with refcount=0 and do refcount_inc() for
+adding each PCM link, while refcount_t API doesn't like refcount_inc()
+performed on zero.
+
+For adapting the proper refcount_t usage, this patch changes the logic
+slightly:
+- The initial refcount is 1, assuming the single list entry
+- The refcount is incremented / decremented at each PCM link addition
+ and deletion
+- ... which allows us concentrating only on the refcount as a release
+ condition
+
+Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204221
+Reported-and-tested-by: Duncan Overbruck <kernel@duncano.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/pcm_native.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/sound/core/pcm_native.c
++++ b/sound/core/pcm_native.c
+@@ -77,7 +77,7 @@ void snd_pcm_group_init(struct snd_pcm_g
+ spin_lock_init(&group->lock);
+ mutex_init(&group->mutex);
+ INIT_LIST_HEAD(&group->substreams);
+- refcount_set(&group->refs, 0);
++ refcount_set(&group->refs, 1);
+ }
+
+ /* define group lock helpers */
+@@ -1096,8 +1096,7 @@ static void snd_pcm_group_unref(struct s
+
+ if (!group)
+ return;
+- do_free = refcount_dec_and_test(&group->refs) &&
+- list_empty(&group->substreams);
++ do_free = refcount_dec_and_test(&group->refs);
+ snd_pcm_group_unlock(group, substream->pcm->nonatomic);
+ if (do_free)
+ kfree(group);
+@@ -2020,6 +2019,7 @@ static int snd_pcm_link(struct snd_pcm_s
+ snd_pcm_group_lock_irq(target_group, nonatomic);
+ snd_pcm_stream_lock(substream1);
+ snd_pcm_group_assign(substream1, target_group);
++ refcount_inc(&target_group->refs);
+ snd_pcm_stream_unlock(substream1);
+ snd_pcm_group_unlock_irq(target_group, nonatomic);
+ _end:
+@@ -2056,13 +2056,14 @@ static int snd_pcm_unlink(struct snd_pcm
+ snd_pcm_group_lock_irq(group, nonatomic);
+
+ relink_to_local(substream);
++ refcount_dec(&group->refs);
+
+ /* detach the last stream, too */
+ if (list_is_singular(&group->substreams)) {
+ relink_to_local(list_first_entry(&group->substreams,
+ struct snd_pcm_substream,
+ link_list));
+- do_free = !refcount_read(&group->refs);
++ do_free = refcount_dec_and_test(&group->refs);
+ }
+
+ snd_pcm_group_unlock_irq(group, nonatomic);
--- /dev/null
+From 49ed96943a8e0c62cc5a9b0a6cfc88be87d1fcec Mon Sep 17 00:00:00 2001
+From: Hridya Valsaraju <hridya@google.com>
+Date: Mon, 15 Jul 2019 12:18:04 -0700
+Subject: binder: prevent transactions to context manager from its own process.
+
+From: Hridya Valsaraju <hridya@google.com>
+
+commit 49ed96943a8e0c62cc5a9b0a6cfc88be87d1fcec upstream.
+
+Currently, a transaction to context manager from its own process
+is prevented by checking if its binder_proc struct is the same as
+that of the sender. However, this would not catch cases where the
+process opens the binder device again and uses the new fd to send
+a transaction to the context manager.
+
+Reported-by: syzbot+8b3c354d33c4ac78bfad@syzkaller.appspotmail.com
+Signed-off-by: Hridya Valsaraju <hridya@google.com>
+Acked-by: Todd Kjos <tkjos@google.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20190715191804.112933-1-hridya@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/android/binder.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/android/binder.c
++++ b/drivers/android/binder.c
+@@ -2988,7 +2988,7 @@ static void binder_transaction(struct bi
+ else
+ return_error = BR_DEAD_REPLY;
+ mutex_unlock(&context->context_mgr_node_lock);
+- if (target_node && target_proc == proc) {
++ if (target_node && target_proc->pid == proc->pid) {
+ binder_user_error("%d:%d got transaction to context manager from process owning it\n",
+ proc->pid, thread->pid);
+ return_error = BR_FAILED_REPLY;
--- /dev/null
+From a56587065094fd96eb4c2b5ad65571daad32156d Mon Sep 17 00:00:00 2001
+From: Martijn Coenen <maco@android.com>
+Date: Tue, 9 Jul 2019 13:09:23 +0200
+Subject: binder: Set end of SG buffer area properly.
+
+From: Martijn Coenen <maco@android.com>
+
+commit a56587065094fd96eb4c2b5ad65571daad32156d upstream.
+
+In case the target node requests a security context, the
+extra_buffers_size is increased with the size of the security context.
+But, that size is not available for use by regular scatter-gather
+buffers; make sure the ending of that buffer is marked correctly.
+
+Acked-by: Todd Kjos <tkjos@google.com>
+Fixes: ec74136ded79 ("binder: create node flag to request sender's security context")
+Signed-off-by: Martijn Coenen <maco@android.com>
+Cc: stable@vger.kernel.org # 5.1+
+Link: https://lore.kernel.org/r/20190709110923.220736-1-maco@android.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/android/binder.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/android/binder.c
++++ b/drivers/android/binder.c
+@@ -3239,7 +3239,8 @@ static void binder_transaction(struct bi
+ buffer_offset = off_start_offset;
+ off_end_offset = off_start_offset + tr->offsets_size;
+ sg_buf_offset = ALIGN(off_end_offset, sizeof(void *));
+- sg_buf_end_offset = sg_buf_offset + extra_buffers_size;
++ sg_buf_end_offset = sg_buf_offset + extra_buffers_size -
++ ALIGN(secctx_sz, sizeof(u64));
+ off_min = 0;
+ for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
+ buffer_offset += sizeof(binder_size_t)) {
--- /dev/null
+From c479450f61c7f1f248c9a54aedacd2a6ca521ff8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?= <sebastien.szymanski@armadeus.com>
+Date: Tue, 7 May 2019 17:27:12 +0200
+Subject: drm/panel: Add support for Armadeus ST0700 Adapt
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+
+commit c479450f61c7f1f248c9a54aedacd2a6ca521ff8 upstream.
+
+This patch adds support for the Armadeus ST0700 Adapt. It comes with a
+Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
+that it can be connected on the TFT header of Armadeus Dev boards.
+
+Cc: stable@vger.kernel.org # v4.19
+Reviewed-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt | 9 +++
+ drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++
+ 2 files changed, 38 insertions(+)
+
+--- /dev/null
++++ b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
+@@ -0,0 +1,9 @@
++Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
++an adapter board.
++
++Required properties:
++- compatible: "armadeus,st0700-adapt"
++- power-supply: see panel-common.txt
++
++Optional properties:
++- backlight: see panel-common.txt
+--- a/drivers/gpu/drm/panel/panel-simple.c
++++ b/drivers/gpu/drm/panel/panel-simple.c
+@@ -446,6 +446,32 @@ static const struct panel_desc ampire_am
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ };
+
++static const struct display_timing santek_st0700i5y_rbslw_f_timing = {
++ .pixelclock = { 26400000, 33300000, 46800000 },
++ .hactive = { 800, 800, 800 },
++ .hfront_porch = { 16, 210, 354 },
++ .hback_porch = { 45, 36, 6 },
++ .hsync_len = { 1, 10, 40 },
++ .vactive = { 480, 480, 480 },
++ .vfront_porch = { 7, 22, 147 },
++ .vback_porch = { 22, 13, 3 },
++ .vsync_len = { 1, 10, 20 },
++ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
++ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE
++};
++
++static const struct panel_desc armadeus_st0700_adapt = {
++ .timings = &santek_st0700i5y_rbslw_f_timing,
++ .num_timings = 1,
++ .bpc = 6,
++ .size = {
++ .width = 154,
++ .height = 86,
++ },
++ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
++ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
++};
++
+ static const struct drm_display_mode auo_b101aw03_mode = {
+ .clock = 51450,
+ .hdisplay = 1024,
+@@ -2571,6 +2597,9 @@ static const struct of_device_id platfor
+ .compatible = "arm,rtsm-display",
+ .data = &arm_rtsm,
+ }, {
++ .compatible = "armadeus,st0700-adapt",
++ .data = &armadeus_st0700_adapt,
++ }, {
+ .compatible = "auo,b101aw03",
+ .data = &auo_b101aw03,
+ }, {
--- /dev/null
+From 1b5621832f9bd9899370ea6928462cd02ebe7dc0 Mon Sep 17 00:00:00 2001
+From: Arseny Solokha <asolokha@kb.kras.ru>
+Date: Tue, 16 Jul 2019 18:12:36 +0700
+Subject: eeprom: make older eeprom drivers select NVMEM_SYSFS
+
+From: Arseny Solokha <asolokha@kb.kras.ru>
+
+commit 1b5621832f9bd9899370ea6928462cd02ebe7dc0 upstream.
+
+misc/eeprom/{at24,at25,eeprom_93xx46} drivers all register their
+corresponding devices in the nvmem framework in compat mode which requires
+nvmem sysfs interface to be present. The latter, however, has been split
+out from nvmem under a separate Kconfig in commit ae0c2d725512 ("nvmem:
+core: add NVMEM_SYSFS Kconfig"). As a result, probing certain I2C-attached
+EEPROMs now fails with
+
+ at24: probe of 0-0050 failed with error -38
+
+because of a stub implementation of nvmem_sysfs_setup_compat()
+in drivers/nvmem/nvmem.h. Update the nvmem dependency for these drivers
+so they could load again:
+
+ at24 0-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
+
+Cc: Adrian Bunk <bunk@kernel.org>
+Cc: Bartosz Golaszewski <brgl@bgdev.pl>
+Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
+Link: https://lore.kernel.org/r/20190716111236.27803-1-asolokha@kb.kras.ru
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/eeprom/Kconfig | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/misc/eeprom/Kconfig
++++ b/drivers/misc/eeprom/Kconfig
+@@ -5,6 +5,7 @@ config EEPROM_AT24
+ tristate "I2C EEPROMs / RAMs / ROMs from most vendors"
+ depends on I2C && SYSFS
+ select NVMEM
++ select NVMEM_SYSFS
+ select REGMAP_I2C
+ help
+ Enable this driver to get read/write support to most I2C EEPROMs
+@@ -34,6 +35,7 @@ config EEPROM_AT25
+ tristate "SPI EEPROMs from most vendors"
+ depends on SPI && SYSFS
+ select NVMEM
++ select NVMEM_SYSFS
+ help
+ Enable this driver to get read/write support to most SPI EEPROMs,
+ after you configure the board init code to know about each eeprom
+@@ -80,6 +82,7 @@ config EEPROM_93XX46
+ depends on SPI && SYSFS
+ select REGMAP
+ select NVMEM
++ select NVMEM_SYSFS
+ help
+ Driver for the microwire EEPROM chipsets 93xx46x. The driver
+ supports both read and write commands and also the command to
--- /dev/null
+From 3d139703d397f6281368047ba7ad1c8bf95aa8ab Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Mon, 8 Jul 2019 15:13:56 +0800
+Subject: fpga-manager: altera-ps-spi: Fix build error
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit 3d139703d397f6281368047ba7ad1c8bf95aa8ab upstream.
+
+If BITREVERSE is m and FPGA_MGR_ALTERA_PS_SPI is y,
+build fails:
+
+drivers/fpga/altera-ps-spi.o: In function `altera_ps_write':
+altera-ps-spi.c:(.text+0x4ec): undefined reference to `byte_rev_table'
+
+Select BITREVERSE to fix this.
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Fixes: fcfe18f885f6 ("fpga-manager: altera-ps-spi: use bitrev8x4")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Moritz Fischer <mdf@kernel.org>
+Link: https://lore.kernel.org/r/20190708071356.50928-1-yuehaibing@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/fpga/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/fpga/Kconfig
++++ b/drivers/fpga/Kconfig
+@@ -40,6 +40,7 @@ config ALTERA_PR_IP_CORE_PLAT
+ config FPGA_MGR_ALTERA_PS_SPI
+ tristate "Altera FPGA Passive Serial over SPI"
+ depends on SPI
++ select BITREVERSE
+ help
+ FPGA manager driver support for Altera Arria/Cyclone/Stratix
+ using the passive serial interface over SPI.
--- /dev/null
+From 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 Mon Sep 17 00:00:00 2001
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+Date: Thu, 11 Jul 2019 21:27:57 +0800
+Subject: hpet: Fix division by zero in hpet_time_div()
+
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+
+commit 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 upstream.
+
+The base value in do_div() called by hpet_time_div() is truncated from
+unsigned long to uint32_t, resulting in a divide-by-zero exception.
+
+UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2
+division by zero
+CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
+ 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561
+ ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20
+ 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0
+Call Trace:
+ [<ffffffff81ad7561>] __dump_stack lib/dump_stack.c:15 [inline]
+ [<ffffffff81ad7561>] dump_stack+0xc1/0x120 lib/dump_stack.c:51
+ [<ffffffff81b8f25e>] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166
+ [<ffffffff81b900cb>] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262
+ [<ffffffff823560dd>] hpet_time_div drivers/char/hpet.c:572 [inline]
+ [<ffffffff823560dd>] hpet_ioctl_common drivers/char/hpet.c:663 [inline]
+ [<ffffffff823560dd>] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577
+ [<ffffffff81e63d56>] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676
+ [<ffffffff81711590>] vfs_ioctl fs/ioctl.c:43 [inline]
+ [<ffffffff81711590>] file_ioctl fs/ioctl.c:470 [inline]
+ [<ffffffff81711590>] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605
+ [<ffffffff81711eb4>] SYSC_ioctl fs/ioctl.c:622 [inline]
+ [<ffffffff81711eb4>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613
+ [<ffffffff82846003>] tracesys_phase2+0x90/0x95
+
+The main C reproducer autogenerated by syzkaller,
+
+ syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
+ memcpy((void*)0x20000100, "/dev/hpet\000", 10);
+ syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
+ syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000);
+
+Fix it by using div64_ul().
+
+Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
+Signed-off-by: Zhang HongJun <zhanghongjun2@huawei.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/hpet.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/char/hpet.c
++++ b/drivers/char/hpet.c
+@@ -567,8 +567,7 @@ static inline unsigned long hpet_time_di
+ unsigned long long m;
+
+ m = hpets->hp_tick_freq + (dis >> 1);
+- do_div(m, dis);
+- return (unsigned long)m;
++ return div64_ul(m, dis);
+ }
+
+ static int
--- /dev/null
+From dbd0f6d6c2a11eb9c31ca9cd454f95bb5713e92e Mon Sep 17 00:00:00 2001
+From: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
+Date: Sat, 13 Jul 2019 11:58:26 +0800
+Subject: io_uring: fix the sequence comparison in io_sequence_defer
+
+From: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
+
+commit dbd0f6d6c2a11eb9c31ca9cd454f95bb5713e92e upstream.
+
+sq->cached_sq_head and cq->cached_cq_tail are both unsigned int. If
+cached_sq_head overflows before cached_cq_tail, then we may miss a
+barrier req. As cached_cq_tail always follows cached_sq_head, the NQ
+should be enough.
+
+Cc: stable@vger.kernel.org
+Fixes: de0617e46717 ("io_uring: add support for marking commands as draining")
+Signed-off-by: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/io_uring.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -425,7 +425,7 @@ static inline bool io_sequence_defer(str
+ if ((req->flags & (REQ_F_IO_DRAIN|REQ_F_IO_DRAINED)) != REQ_F_IO_DRAIN)
+ return false;
+
+- return req->sequence > ctx->cached_cq_tail + ctx->sq_ring->dropped;
++ return req->sequence != ctx->cached_cq_tail + ctx->sq_ring->dropped;
+ }
+
+ static struct io_kiocb *io_get_deferred_req(struct io_ring_ctx *ctx)
--- /dev/null
+From 9eed17d37c77171cf5ffb95c4257f87df3cd4c8f Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sat, 20 Jul 2019 19:08:48 +0100
+Subject: iommu/iova: Remove stale cached32_node
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 9eed17d37c77171cf5ffb95c4257f87df3cd4c8f upstream.
+
+Since the cached32_node is allowed to be advanced above dma_32bit_pfn
+(to provide a shortcut into the limited range), we need to be careful to
+remove the to be freed node if it is the cached32_node.
+
+[ 48.477773] BUG: KASAN: use-after-free in __cached_rbnode_delete_update+0x68/0x110
+[ 48.477812] Read of size 8 at addr ffff88870fc19020 by task kworker/u8:1/37
+[ 48.477843]
+[ 48.477879] CPU: 1 PID: 37 Comm: kworker/u8:1 Tainted: G U 5.2.0+ #735
+[ 48.477915] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
+[ 48.478047] Workqueue: i915 __i915_gem_free_work [i915]
+[ 48.478075] Call Trace:
+[ 48.478111] dump_stack+0x5b/0x90
+[ 48.478137] print_address_description+0x67/0x237
+[ 48.478178] ? __cached_rbnode_delete_update+0x68/0x110
+[ 48.478212] __kasan_report.cold.3+0x1c/0x38
+[ 48.478240] ? __cached_rbnode_delete_update+0x68/0x110
+[ 48.478280] ? __cached_rbnode_delete_update+0x68/0x110
+[ 48.478308] __cached_rbnode_delete_update+0x68/0x110
+[ 48.478344] private_free_iova+0x2b/0x60
+[ 48.478378] iova_magazine_free_pfns+0x46/0xa0
+[ 48.478403] free_iova_fast+0x277/0x340
+[ 48.478443] fq_ring_free+0x15a/0x1a0
+[ 48.478473] queue_iova+0x19c/0x1f0
+[ 48.478597] cleanup_page_dma.isra.64+0x62/0xb0 [i915]
+[ 48.478712] __gen8_ppgtt_cleanup+0x63/0x80 [i915]
+[ 48.478826] __gen8_ppgtt_cleanup+0x42/0x80 [i915]
+[ 48.478940] __gen8_ppgtt_clear+0x433/0x4b0 [i915]
+[ 48.479053] __gen8_ppgtt_clear+0x462/0x4b0 [i915]
+[ 48.479081] ? __sg_free_table+0x9e/0xf0
+[ 48.479116] ? kfree+0x7f/0x150
+[ 48.479234] i915_vma_unbind+0x1e2/0x240 [i915]
+[ 48.479352] i915_vma_destroy+0x3a/0x280 [i915]
+[ 48.479465] __i915_gem_free_objects+0xf0/0x2d0 [i915]
+[ 48.479579] __i915_gem_free_work+0x41/0xa0 [i915]
+[ 48.479607] process_one_work+0x495/0x710
+[ 48.479642] worker_thread+0x4c7/0x6f0
+[ 48.479687] ? process_one_work+0x710/0x710
+[ 48.479724] kthread+0x1b2/0x1d0
+[ 48.479774] ? kthread_create_worker_on_cpu+0xa0/0xa0
+[ 48.479820] ret_from_fork+0x1f/0x30
+[ 48.479864]
+[ 48.479907] Allocated by task 631:
+[ 48.479944] save_stack+0x19/0x80
+[ 48.479994] __kasan_kmalloc.constprop.6+0xc1/0xd0
+[ 48.480038] kmem_cache_alloc+0x91/0xf0
+[ 48.480082] alloc_iova+0x2b/0x1e0
+[ 48.480125] alloc_iova_fast+0x58/0x376
+[ 48.480166] intel_alloc_iova+0x90/0xc0
+[ 48.480214] intel_map_sg+0xde/0x1f0
+[ 48.480343] i915_gem_gtt_prepare_pages+0xb8/0x170 [i915]
+[ 48.480465] huge_get_pages+0x232/0x2b0 [i915]
+[ 48.480590] ____i915_gem_object_get_pages+0x40/0xb0 [i915]
+[ 48.480712] __i915_gem_object_get_pages+0x90/0xa0 [i915]
+[ 48.480834] i915_gem_object_prepare_write+0x2d6/0x330 [i915]
+[ 48.480955] create_test_object.isra.54+0x1a9/0x3e0 [i915]
+[ 48.481075] igt_shared_ctx_exec+0x365/0x3c0 [i915]
+[ 48.481210] __i915_subtests.cold.4+0x30/0x92 [i915]
+[ 48.481341] __run_selftests.cold.3+0xa9/0x119 [i915]
+[ 48.481466] i915_live_selftests+0x3c/0x70 [i915]
+[ 48.481583] i915_pci_probe+0xe7/0x220 [i915]
+[ 48.481620] pci_device_probe+0xe0/0x180
+[ 48.481665] really_probe+0x163/0x4e0
+[ 48.481710] device_driver_attach+0x85/0x90
+[ 48.481750] __driver_attach+0xa5/0x180
+[ 48.481796] bus_for_each_dev+0xda/0x130
+[ 48.481831] bus_add_driver+0x205/0x2e0
+[ 48.481882] driver_register+0xca/0x140
+[ 48.481927] do_one_initcall+0x6c/0x1af
+[ 48.481970] do_init_module+0x106/0x350
+[ 48.482010] load_module+0x3d2c/0x3ea0
+[ 48.482058] __do_sys_finit_module+0x110/0x180
+[ 48.482102] do_syscall_64+0x62/0x1f0
+[ 48.482147] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+[ 48.482190]
+[ 48.482224] Freed by task 37:
+[ 48.482273] save_stack+0x19/0x80
+[ 48.482318] __kasan_slab_free+0x12e/0x180
+[ 48.482363] kmem_cache_free+0x70/0x140
+[ 48.482406] __free_iova+0x1d/0x30
+[ 48.482445] fq_ring_free+0x15a/0x1a0
+[ 48.482490] queue_iova+0x19c/0x1f0
+[ 48.482624] cleanup_page_dma.isra.64+0x62/0xb0 [i915]
+[ 48.482749] __gen8_ppgtt_cleanup+0x63/0x80 [i915]
+[ 48.482873] __gen8_ppgtt_cleanup+0x42/0x80 [i915]
+[ 48.482999] __gen8_ppgtt_clear+0x433/0x4b0 [i915]
+[ 48.483123] __gen8_ppgtt_clear+0x462/0x4b0 [i915]
+[ 48.483250] i915_vma_unbind+0x1e2/0x240 [i915]
+[ 48.483378] i915_vma_destroy+0x3a/0x280 [i915]
+[ 48.483500] __i915_gem_free_objects+0xf0/0x2d0 [i915]
+[ 48.483622] __i915_gem_free_work+0x41/0xa0 [i915]
+[ 48.483659] process_one_work+0x495/0x710
+[ 48.483704] worker_thread+0x4c7/0x6f0
+[ 48.483748] kthread+0x1b2/0x1d0
+[ 48.483787] ret_from_fork+0x1f/0x30
+[ 48.483831]
+[ 48.483868] The buggy address belongs to the object at ffff88870fc19000
+[ 48.483868] which belongs to the cache iommu_iova of size 40
+[ 48.483920] The buggy address is located 32 bytes inside of
+[ 48.483920] 40-byte region [ffff88870fc19000, ffff88870fc19028)
+[ 48.483964] The buggy address belongs to the page:
+[ 48.484006] page:ffffea001c3f0600 refcount:1 mapcount:0 mapping:ffff8888181a91c0 index:0x0 compound_mapcount: 0
+[ 48.484045] flags: 0x8000000000010200(slab|head)
+[ 48.484096] raw: 8000000000010200 ffffea001c421a08 ffffea001c447e88 ffff8888181a91c0
+[ 48.484141] raw: 0000000000000000 0000000000120012 00000001ffffffff 0000000000000000
+[ 48.484188] page dumped because: kasan: bad access detected
+[ 48.484230]
+[ 48.484265] Memory state around the buggy address:
+[ 48.484314] ffff88870fc18f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+[ 48.484361] ffff88870fc18f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+[ 48.484406] >ffff88870fc19000: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
+[ 48.484451] ^
+[ 48.484494] ffff88870fc19080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+[ 48.484530] ffff88870fc19100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108602
+Fixes: e60aa7b53845 ("iommu/iova: Extend rbtree node caching")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Joerg Roedel <jroedel@suse.de>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: <stable@vger.kernel.org> # v4.15+
+Reviewed-by: Robin Murphy <robin.murphy@arm.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
+@@ -137,8 +137,9 @@ __cached_rbnode_delete_update(struct iov
+ struct iova *cached_iova;
+
+ cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
+- if (free->pfn_hi < iovad->dma_32bit_pfn &&
+- free->pfn_lo >= cached_iova->pfn_lo) {
++ if (free == cached_iova ||
++ (free->pfn_hi < iovad->dma_32bit_pfn &&
++ free->pfn_lo >= cached_iova->pfn_lo)) {
+ iovad->cached32_node = rb_next(&free->node);
+ iovad->max32_alloc_size = iovad->dma_32bit_pfn;
+ }
--- /dev/null
+From effa467870c7612012885df4e246bdb8ffd8e44c Mon Sep 17 00:00:00 2001
+From: Dmitry Safonov <dima@arista.com>
+Date: Tue, 16 Jul 2019 22:38:05 +0100
+Subject: iommu/vt-d: Don't queue_iova() if there is no flush queue
+
+From: Dmitry Safonov <dima@arista.com>
+
+commit effa467870c7612012885df4e246bdb8ffd8e44c upstream.
+
+Intel VT-d driver was reworked to use common deferred flushing
+implementation. Previously there was one global per-cpu flush queue,
+afterwards - one per domain.
+
+Before deferring a flush, the queue should be allocated and initialized.
+
+Currently only domains with IOMMU_DOMAIN_DMA type initialize their flush
+queue. It's probably worth to init it for static or unmanaged domains
+too, but it may be arguable - I'm leaving it to iommu folks.
+
+Prevent queuing an iova flush if the domain doesn't have a queue.
+The defensive check seems to be worth to keep even if queue would be
+initialized for all kinds of domains. And is easy backportable.
+
+On 4.19.43 stable kernel it has a user-visible effect: previously for
+devices in si domain there were crashes, on sata devices:
+
+ BUG: spinlock bad magic on CPU#6, swapper/0/1
+ lock: 0xffff88844f582008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
+ CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #1
+ Call Trace:
+ <IRQ>
+ dump_stack+0x61/0x7e
+ spin_bug+0x9d/0xa3
+ do_raw_spin_lock+0x22/0x8e
+ _raw_spin_lock_irqsave+0x32/0x3a
+ queue_iova+0x45/0x115
+ intel_unmap+0x107/0x113
+ intel_unmap_sg+0x6b/0x76
+ __ata_qc_complete+0x7f/0x103
+ ata_qc_complete+0x9b/0x26a
+ ata_qc_complete_multiple+0xd0/0xe3
+ ahci_handle_port_interrupt+0x3ee/0x48a
+ ahci_handle_port_intr+0x73/0xa9
+ ahci_single_level_irq_intr+0x40/0x60
+ __handle_irq_event_percpu+0x7f/0x19a
+ handle_irq_event_percpu+0x32/0x72
+ handle_irq_event+0x38/0x56
+ handle_edge_irq+0x102/0x121
+ handle_irq+0x147/0x15c
+ do_IRQ+0x66/0xf2
+ common_interrupt+0xf/0xf
+ RIP: 0010:__do_softirq+0x8c/0x2df
+
+The same for usb devices that use ehci-pci:
+ BUG: spinlock bad magic on CPU#0, swapper/0/1
+ lock: 0xffff88844f402008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
+ CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #4
+ Call Trace:
+ <IRQ>
+ dump_stack+0x61/0x7e
+ spin_bug+0x9d/0xa3
+ do_raw_spin_lock+0x22/0x8e
+ _raw_spin_lock_irqsave+0x32/0x3a
+ queue_iova+0x77/0x145
+ intel_unmap+0x107/0x113
+ intel_unmap_page+0xe/0x10
+ usb_hcd_unmap_urb_setup_for_dma+0x53/0x9d
+ usb_hcd_unmap_urb_for_dma+0x17/0x100
+ unmap_urb_for_dma+0x22/0x24
+ __usb_hcd_giveback_urb+0x51/0xc3
+ usb_giveback_urb_bh+0x97/0xde
+ tasklet_action_common.isra.4+0x5f/0xa1
+ tasklet_action+0x2d/0x30
+ __do_softirq+0x138/0x2df
+ irq_exit+0x7d/0x8b
+ smp_apic_timer_interrupt+0x10f/0x151
+ apic_timer_interrupt+0xf/0x20
+ </IRQ>
+ RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39
+
+Cc: David Woodhouse <dwmw2@infradead.org>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: Lu Baolu <baolu.lu@linux.intel.com>
+Cc: iommu@lists.linux-foundation.org
+Cc: <stable@vger.kernel.org> # 4.14+
+Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing")
+Signed-off-by: Dmitry Safonov <dima@arista.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/intel-iommu.c | 3 ++-
+ drivers/iommu/iova.c | 18 ++++++++++++++----
+ include/linux/iova.h | 6 ++++++
+ 3 files changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/iommu/intel-iommu.c
++++ b/drivers/iommu/intel-iommu.c
+@@ -3752,7 +3752,8 @@ static void intel_unmap(struct device *d
+
+ freelist = domain_unmap(domain, start_pfn, last_pfn);
+
+- if (intel_iommu_strict || (pdev && pdev->untrusted)) {
++ if (intel_iommu_strict || (pdev && pdev->untrusted) ||
++ !has_iova_flush_queue(&domain->iovad)) {
+ iommu_flush_iotlb_psi(iommu, domain, start_pfn,
+ nrpages, !freelist, 0);
+ /* free iova */
+--- a/drivers/iommu/iova.c
++++ b/drivers/iommu/iova.c
+@@ -54,9 +54,14 @@ init_iova_domain(struct iova_domain *iov
+ }
+ EXPORT_SYMBOL_GPL(init_iova_domain);
+
++bool has_iova_flush_queue(struct iova_domain *iovad)
++{
++ return !!iovad->fq;
++}
++
+ static void free_iova_flush_queue(struct iova_domain *iovad)
+ {
+- if (!iovad->fq)
++ if (!has_iova_flush_queue(iovad))
+ return;
+
+ if (timer_pending(&iovad->fq_timer))
+@@ -74,13 +79,14 @@ static void free_iova_flush_queue(struct
+ int init_iova_flush_queue(struct iova_domain *iovad,
+ iova_flush_cb flush_cb, iova_entry_dtor entry_dtor)
+ {
++ struct iova_fq __percpu *queue;
+ int cpu;
+
+ atomic64_set(&iovad->fq_flush_start_cnt, 0);
+ atomic64_set(&iovad->fq_flush_finish_cnt, 0);
+
+- iovad->fq = alloc_percpu(struct iova_fq);
+- if (!iovad->fq)
++ queue = alloc_percpu(struct iova_fq);
++ if (!queue)
+ return -ENOMEM;
+
+ iovad->flush_cb = flush_cb;
+@@ -89,13 +95,17 @@ int init_iova_flush_queue(struct iova_do
+ for_each_possible_cpu(cpu) {
+ struct iova_fq *fq;
+
+- fq = per_cpu_ptr(iovad->fq, cpu);
++ fq = per_cpu_ptr(queue, cpu);
+ fq->head = 0;
+ fq->tail = 0;
+
+ spin_lock_init(&fq->lock);
+ }
+
++ smp_wmb();
++
++ iovad->fq = queue;
++
+ timer_setup(&iovad->fq_timer, fq_flush_timeout, 0);
+ atomic_set(&iovad->fq_timer_on, 0);
+
+--- a/include/linux/iova.h
++++ b/include/linux/iova.h
+@@ -155,6 +155,7 @@ struct iova *reserve_iova(struct iova_do
+ void copy_reserved_iova(struct iova_domain *from, struct iova_domain *to);
+ void init_iova_domain(struct iova_domain *iovad, unsigned long granule,
+ unsigned long start_pfn);
++bool has_iova_flush_queue(struct iova_domain *iovad);
+ int init_iova_flush_queue(struct iova_domain *iovad,
+ iova_flush_cb flush_cb, iova_entry_dtor entry_dtor);
+ struct iova *find_iova(struct iova_domain *iovad, unsigned long pfn);
+@@ -235,6 +236,11 @@ static inline void init_iova_domain(stru
+ {
+ }
+
++bool has_iova_flush_queue(struct iova_domain *iovad)
++{
++ return false;
++}
++
+ static inline int init_iova_flush_queue(struct iova_domain *iovad,
+ iova_flush_cb flush_cb,
+ iova_entry_dtor entry_dtor)
--- /dev/null
+From 1be8624a0cbef720e8da39a15971e01abffc865b Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Fri, 12 Jul 2019 12:58:14 +0300
+Subject: mei: me: add mule creek canyon (EHL) device ids
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit 1be8624a0cbef720e8da39a15971e01abffc865b upstream.
+
+Add Mule Creek Canyon (PCH) MEI device ids for Elkhart Lake (EHL) Platform.
+
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20190712095814.20746-1-tomas.winkler@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/mei/hw-me-regs.h | 3 +++
+ drivers/misc/mei/pci-me.c | 3 +++
+ 2 files changed, 6 insertions(+)
+
+--- a/drivers/misc/mei/hw-me-regs.h
++++ b/drivers/misc/mei/hw-me-regs.h
+@@ -81,6 +81,9 @@
+
+ #define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */
+
++#define MEI_DEV_ID_MCC 0x4B70 /* Mule Creek Canyon (EHL) */
++#define MEI_DEV_ID_MCC_4 0x4B75 /* Mule Creek Canyon 4 (EHL) */
++
+ /*
+ * MEI HW Section
+ */
+--- a/drivers/misc/mei/pci-me.c
++++ b/drivers/misc/mei/pci-me.c
+@@ -98,6 +98,9 @@ static const struct pci_device_id mei_me
+
+ {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
+
++ {MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH12_CFG)},
++ {MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)},
++
+ /* required last entry */
+ {0, }
+ };
--- /dev/null
+From b4fc36e60f25cf22bf8b7b015a701015740c3743 Mon Sep 17 00:00:00 2001
+From: Shawn Anastasio <shawn@anastas.io>
+Date: Wed, 17 Jul 2019 18:54:37 -0500
+Subject: powerpc/dma: Fix invalid DMA mmap behavior
+
+From: Shawn Anastasio <shawn@anastas.io>
+
+commit b4fc36e60f25cf22bf8b7b015a701015740c3743 upstream.
+
+The refactor of powerpc DMA functions in commit 6666cc17d780
+("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
+changes the way DMA mappings are handled on powerpc.
+Since this change, all mapped pages are marked as cache-inhibited
+through the default implementation of arch_dma_mmap_pgprot.
+This differs from the previous behavior of only marking pages
+in noncoherent mappings as cache-inhibited and has resulted in
+sporadic system crashes in certain hardware configurations and
+workloads (see Bugzilla).
+
+This commit restores the previous correct behavior by providing
+an implementation of arch_dma_mmap_pgprot that only marks
+pages in noncoherent mappings as cache-inhibited. As this behavior
+should be universal for all powerpc platforms a new file,
+dma-generic.c, was created to store it.
+
+Fixes: 6666cc17d780 ("powerpc/dma: remove dma_nommu_mmap_coherent")
+# NOTE: fixes commit 6666cc17d780 released in v5.1.
+# Consider a stable tag:
+# Cc: stable@vger.kernel.org # v5.1+
+# NOTE: fixes commit 6666cc17d780 released in v5.1.
+# Consider a stable tag:
+# Cc: stable@vger.kernel.org # v5.1+
+Cc: stable@vger.kernel.org # v5.1+
+Signed-off-by: Shawn Anastasio <shawn@anastas.io>
+Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190717235437.12908-1-shawn@anastas.io
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/Kconfig | 1 +
+ arch/powerpc/kernel/Makefile | 3 ++-
+ arch/powerpc/kernel/dma-common.c | 17 +++++++++++++++++
+ 3 files changed, 20 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/Kconfig
++++ b/arch/powerpc/Kconfig
+@@ -121,6 +121,7 @@ config PPC
+ select ARCH_32BIT_OFF_T if PPC32
+ select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEVMEM_IS_ALLOWED
++ select ARCH_HAS_DMA_MMAP_PGPROT
+ select ARCH_HAS_ELF_RANDOMIZE
+ select ARCH_HAS_FORTIFY_SOURCE
+ select ARCH_HAS_GCOV_PROFILE_ALL
+--- a/arch/powerpc/kernel/Makefile
++++ b/arch/powerpc/kernel/Makefile
+@@ -49,7 +49,8 @@ obj-y := cputable.o ptrace.o syscalls
+ signal.o sysfs.o cacheinfo.o time.o \
+ prom.o traps.o setup-common.o \
+ udbg.o misc.o io.o misc_$(BITS).o \
+- of_platform.o prom_parse.o
++ of_platform.o prom_parse.o \
++ dma-common.o
+ obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
+ signal_64.o ptrace32.o \
+ paca.o nvram_64.o firmware.o
+--- /dev/null
++++ b/arch/powerpc/kernel/dma-common.c
+@@ -0,0 +1,17 @@
++// SPDX-License-Identifier: GPL-2.0-or-later
++/*
++ * Contains common dma routines for all powerpc platforms.
++ *
++ * Copyright (C) 2019 Shawn Anastasio.
++ */
++
++#include <linux/mm.h>
++#include <linux/dma-noncoherent.h>
++
++pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
++ unsigned long attrs)
++{
++ if (!dev_is_dma_coherent(dev))
++ return pgprot_noncached(prot);
++ return prot;
++}
--- /dev/null
+From da0ef93310e67ae6902efded60b6724dab27a5d1 Mon Sep 17 00:00:00 2001
+From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+Date: Wed, 10 Jul 2019 15:20:18 +1000
+Subject: powerpc/mm: Limit rma_size to 1TB when running without HV mode
+
+From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+
+commit da0ef93310e67ae6902efded60b6724dab27a5d1 upstream.
+
+The virtual real mode addressing (VRMA) mechanism is used when a
+partition is using HPT (Hash Page Table) translation and performs real
+mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this mode
+effective address bits 0:23 are treated as zero (i.e. the access is
+aliased to 0) and the access is performed using an implicit 1TB SLB
+entry.
+
+The size of the RMA (Real Memory Area) is communicated to the guest as
+the size of the first memory region in the device tree. And because of
+the mechanism described above can be expected to not exceed 1TB. In
+the event that the host erroneously represents the RMA as being larger
+than 1TB, guest accesses in real mode to memory addresses above 1TB
+will be aliased down to below 1TB. This means that a memory access
+performed in real mode may differ to one performed in virtual mode for
+the same memory address, which would likely have unintended
+consequences.
+
+To avoid this outcome have the guest explicitly limit the size of the
+RMA to the current maximum, which is 1TB. This means that even if the
+first memory block is larger than 1TB, only the first 1TB should be
+accessed in real mode.
+
+Fixes: c610d65c0ad0 ("powerpc/pseries: lift RTAS limit for hash")
+Cc: stable@vger.kernel.org # v4.16+
+Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
+Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190710052018.14628-1-sjitindarsingh@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/mm/book3s64/hash_utils.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/powerpc/mm/book3s64/hash_utils.c
++++ b/arch/powerpc/mm/book3s64/hash_utils.c
+@@ -1901,11 +1901,20 @@ void hash__setup_initial_memory_limit(ph
+ *
+ * For guests on platforms before POWER9, we clamp the it limit to 1G
+ * to avoid some funky things such as RTAS bugs etc...
++ *
++ * On POWER9 we limit to 1TB in case the host erroneously told us that
++ * the RMA was >1TB. Effective address bits 0:23 are treated as zero
++ * (meaning the access is aliased to zero i.e. addr = addr % 1TB)
++ * for virtual real mode addressing and so it doesn't make sense to
++ * have an area larger than 1TB as it can't be addressed.
+ */
+ if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
+ ppc64_rma_size = first_memblock_size;
+ if (!early_cpu_has_feature(CPU_FTR_ARCH_300))
+ ppc64_rma_size = min_t(u64, ppc64_rma_size, 0x40000000);
++ else
++ ppc64_rma_size = min_t(u64, ppc64_rma_size,
++ 1UL << SID_SHIFT_1T);
+
+ /* Finally limit subsequent allocations */
+ memblock_set_current_limit(ppc64_rma_size);
--- /dev/null
+From 28d2a6e6684d9851905f379816d8a4d03587ed94 Mon Sep 17 00:00:00 2001
+From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+Date: Wed, 3 Jul 2019 11:20:21 +1000
+Subject: powerpc/pmu: Set pmcregs_in_use in paca when running as LPAR
+
+From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+
+commit 28d2a6e6684d9851905f379816d8a4d03587ed94 upstream.
+
+The ability to run nested guests under KVM means that a guest can also
+act as a hypervisor for it's own nested guest. Currently
+ppc_set_pmu_inuse() assumes that either FW_FEATURE_LPAR is set,
+indicating a guest environment, and so sets the pmcregs_in_use flag in
+the lppaca, or that it isn't set, indicating a hypervisor environment,
+and so sets the pmcregs_in_use flag in the paca.
+
+The pmcregs_in_use flag in the lppaca is used to communicate this
+information to a hypervisor and so must be set in a guest environment.
+The pmcregs_in_use flag in the paca is used by KVM code to determine
+whether the host state of the performance monitoring unit (PMU) must
+be saved and restored when running a guest.
+
+Thus when a guest also acts as a hypervisor it must set this bit in
+both places since it needs to ensure both that the real hypervisor
+saves it's PMU registers when it runs (requires pmcregs_in_use flag in
+lppaca), and that it saves it's own PMU registers when running a
+nested guest (requires pmcregs_in_use flag in paca).
+
+Modify ppc_set_pmu_inuse() so that the pmcregs_in_use bit is set in
+both the lppaca and the paca when a guest (LPAR) is running with the
+capability of running it's own guests (CONFIG_KVM_BOOK3S_HV_POSSIBLE).
+
+Fixes: 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
+Cc: stable@vger.kernel.org # v4.20+
+Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190703012022.15644-2-sjitindarsingh@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/pmc.h | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/include/asm/pmc.h
++++ b/arch/powerpc/include/asm/pmc.h
+@@ -27,11 +27,10 @@ static inline void ppc_set_pmu_inuse(int
+ #ifdef CONFIG_PPC_PSERIES
+ get_lppaca()->pmcregs_in_use = inuse;
+ #endif
+- } else {
++ }
+ #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+- get_paca()->pmcregs_in_use = inuse;
++ get_paca()->pmcregs_in_use = inuse;
+ #endif
+- }
+ #endif
+ }
+
--- /dev/null
+From f16d80b75a096c52354c6e0a574993f3b0dfbdfe Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Fri, 19 Jul 2019 15:05:02 +1000
+Subject: powerpc/tm: Fix oops on sigreturn on systems without TM
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit f16d80b75a096c52354c6e0a574993f3b0dfbdfe upstream.
+
+On systems like P9 powernv where we have no TM (or P8 booted with
+ppc_tm=off), userspace can construct a signal context which still has
+the MSR TS bits set. The kernel tries to restore this context which
+results in the following crash:
+
+ Unexpected TM Bad Thing exception at c0000000000022fc (msr 0x8000000102a03031) tm_scratch=800000020280f033
+ Oops: Unrecoverable exception, sig: 6 [#1]
+ LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
+ Modules linked in:
+ CPU: 0 PID: 1636 Comm: sigfuz Not tainted 5.2.0-11043-g0a8ad0ffa4 #69
+ NIP: c0000000000022fc LR: 00007fffb2d67e48 CTR: 0000000000000000
+ REGS: c00000003fffbd70 TRAP: 0700 Not tainted (5.2.0-11045-g7142b497d8)
+ MSR: 8000000102a03031 <SF,VEC,VSX,FP,ME,IR,DR,LE,TM[E]> CR: 42004242 XER: 00000000
+ CFAR: c0000000000022e0 IRQMASK: 0
+ GPR00: 0000000000000072 00007fffb2b6e560 00007fffb2d87f00 0000000000000669
+ GPR04: 00007fffb2b6e728 0000000000000000 0000000000000000 00007fffb2b6f2a8
+ GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+ GPR12: 0000000000000000 00007fffb2b76900 0000000000000000 0000000000000000
+ GPR16: 00007fffb2370000 00007fffb2d84390 00007fffea3a15ac 000001000a250420
+ GPR20: 00007fffb2b6f260 0000000010001770 0000000000000000 0000000000000000
+ GPR24: 00007fffb2d843a0 00007fffea3a14a0 0000000000010000 0000000000800000
+ GPR28: 00007fffea3a14d8 00000000003d0f00 0000000000000000 00007fffb2b6e728
+ NIP [c0000000000022fc] rfi_flush_fallback+0x7c/0x80
+ LR [00007fffb2d67e48] 0x7fffb2d67e48
+ Call Trace:
+ Instruction dump:
+ e96a0220 e96a02a8 e96a0330 e96a03b8 394a0400 4200ffdc 7d2903a6 e92d0c00
+ e94d0c08 e96d0c10 e82d0c18 7db242a6 <4c000024> 7db243a6 7db142a6 f82d0c18
+
+The problem is the signal code assumes TM is enabled when
+CONFIG_PPC_TRANSACTIONAL_MEM is enabled. This may not be the case as
+with P9 powernv or if `ppc_tm=off` is used on P8.
+
+This means any local user can crash the system.
+
+Fix the problem by returning a bad stack frame to the user if they try
+to set the MSR TS bits with sigreturn() on systems where TM is not
+supported.
+
+Found with sigfuz kernel selftest on P9.
+
+This fixes CVE-2019-13648.
+
+Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
+Cc: stable@vger.kernel.org # v3.9
+Reported-by: Praveen Pandey <Praveen.Pandey@in.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190719050502.405-1-mikey@neuling.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/signal_32.c | 3 +++
+ arch/powerpc/kernel/signal_64.c | 5 +++++
+ 2 files changed, 8 insertions(+)
+
+--- a/arch/powerpc/kernel/signal_32.c
++++ b/arch/powerpc/kernel/signal_32.c
+@@ -1198,6 +1198,9 @@ SYSCALL_DEFINE0(rt_sigreturn)
+ goto bad;
+
+ if (MSR_TM_ACTIVE(msr_hi<<32)) {
++ /* Trying to start TM on non TM system */
++ if (!cpu_has_feature(CPU_FTR_TM))
++ goto bad;
+ /* We only recheckpoint on return if we're
+ * transaction.
+ */
+--- a/arch/powerpc/kernel/signal_64.c
++++ b/arch/powerpc/kernel/signal_64.c
+@@ -771,6 +771,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
+ if (MSR_TM_ACTIVE(msr)) {
+ /* We recheckpoint on return. */
+ struct ucontext __user *uc_transact;
++
++ /* Trying to start TM on non TM system */
++ if (!cpu_has_feature(CPU_FTR_TM))
++ goto badframe;
++
+ if (__get_user(uc_transact, &uc->uc_link))
+ goto badframe;
+ if (restore_tm_sigcontexts(current, &uc->uc_mcontext,
--- /dev/null
+From 4d202c8c8ed3822327285747db1765967110b274 Mon Sep 17 00:00:00 2001
+From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
+Date: Wed, 17 Jul 2019 16:05:24 +0530
+Subject: powerpc/xive: Fix loop exit-condition in xive_find_target_in_mask()
+
+From: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+
+commit 4d202c8c8ed3822327285747db1765967110b274 upstream.
+
+xive_find_target_in_mask() has the following for(;;) loop which has a
+bug when @first == cpumask_first(@mask) and condition 1 fails to hold
+for every CPU in @mask. In this case we loop forever in the for-loop.
+
+ first = cpu;
+ for (;;) {
+ if (cpu_online(cpu) && xive_try_pick_target(cpu)) // condition 1
+ return cpu;
+ cpu = cpumask_next(cpu, mask);
+ if (cpu == first) // condition 2
+ break;
+
+ if (cpu >= nr_cpu_ids) // condition 3
+ cpu = cpumask_first(mask);
+ }
+
+This is because, when @first == cpumask_first(@mask), we never hit the
+condition 2 (cpu == first) since prior to this check, we would have
+executed "cpu = cpumask_next(cpu, mask)" which will set the value of
+@cpu to a value greater than @first or to nr_cpus_ids. When this is
+coupled with the fact that condition 1 is not met, we will never exit
+this loop.
+
+This was discovered by the hard-lockup detector while running LTP test
+concurrently with SMT switch tests.
+
+ watchdog: CPU 12 detected hard LOCKUP on other CPUs 68
+ watchdog: CPU 12 TB:85587019220796, last SMP heartbeat TB:85578827223399 (15999ms ago)
+ watchdog: CPU 68 Hard LOCKUP
+ watchdog: CPU 68 TB:85587019361273, last heartbeat TB:85576815065016 (19930ms ago)
+ CPU: 68 PID: 45050 Comm: hxediag Kdump: loaded Not tainted 4.18.0-100.el8.ppc64le #1
+ NIP: c0000000006f5578 LR: c000000000cba9ec CTR: 0000000000000000
+ REGS: c000201fff3c7d80 TRAP: 0100 Not tainted (4.18.0-100.el8.ppc64le)
+ MSR: 9000000002883033 <SF,HV,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 24028424 XER: 00000000
+ CFAR: c0000000006f558c IRQMASK: 1
+ GPR00: c0000000000afc58 c000201c01c43400 c0000000015ce500 c000201cae26ec18
+ GPR04: 0000000000000800 0000000000000540 0000000000000800 00000000000000f8
+ GPR08: 0000000000000020 00000000000000a8 0000000080000000 c00800001a1beed8
+ GPR12: c0000000000b1410 c000201fff7f4c00 0000000000000000 0000000000000000
+ GPR16: 0000000000000000 0000000000000000 0000000000000540 0000000000000001
+ GPR20: 0000000000000048 0000000010110000 c00800001a1e3780 c000201cae26ed18
+ GPR24: 0000000000000000 c000201cae26ed8c 0000000000000001 c000000001116bc0
+ GPR28: c000000001601ee8 c000000001602494 c000201cae26ec18 000000000000001f
+ NIP [c0000000006f5578] find_next_bit+0x38/0x90
+ LR [c000000000cba9ec] cpumask_next+0x2c/0x50
+ Call Trace:
+ [c000201c01c43400] [c000201cae26ec18] 0xc000201cae26ec18 (unreliable)
+ [c000201c01c43420] [c0000000000afc58] xive_find_target_in_mask+0x1b8/0x240
+ [c000201c01c43470] [c0000000000b0228] xive_pick_irq_target.isra.3+0x168/0x1f0
+ [c000201c01c435c0] [c0000000000b1470] xive_irq_startup+0x60/0x260
+ [c000201c01c43640] [c0000000001d8328] __irq_startup+0x58/0xf0
+ [c000201c01c43670] [c0000000001d844c] irq_startup+0x8c/0x1a0
+ [c000201c01c436b0] [c0000000001d57b0] __setup_irq+0x9f0/0xa90
+ [c000201c01c43760] [c0000000001d5aa0] request_threaded_irq+0x140/0x220
+ [c000201c01c437d0] [c00800001a17b3d4] bnx2x_nic_load+0x188c/0x3040 [bnx2x]
+ [c000201c01c43950] [c00800001a187c44] bnx2x_self_test+0x1fc/0x1f70 [bnx2x]
+ [c000201c01c43a90] [c000000000adc748] dev_ethtool+0x11d8/0x2cb0
+ [c000201c01c43b60] [c000000000b0b61c] dev_ioctl+0x5ac/0xa50
+ [c000201c01c43bf0] [c000000000a8d4ec] sock_do_ioctl+0xbc/0x1b0
+ [c000201c01c43c60] [c000000000a8dfb8] sock_ioctl+0x258/0x4f0
+ [c000201c01c43d20] [c0000000004c9704] do_vfs_ioctl+0xd4/0xa70
+ [c000201c01c43de0] [c0000000004ca274] sys_ioctl+0xc4/0x160
+ [c000201c01c43e30] [c00000000000b388] system_call+0x5c/0x70
+ Instruction dump:
+ 78aad182 54a806be 3920ffff 78a50664 794a1f24 7d294036 7d43502a 7d295039
+ 4182001c 48000034 78a9d182 79291f24 <7d23482a> 2fa90000 409e0020 38a50040
+
+To fix this, move the check for condition 2 after the check for
+condition 3, so that we are able to break out of the loop soon after
+iterating through all the CPUs in the @mask in the problem case. Use
+do..while() to achieve this.
+
+Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller")
+Cc: stable@vger.kernel.org # v4.12+
+Reported-by: Indira P. Joga <indira.priya@in.ibm.com>
+Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/1563359724-13931-1-git-send-email-ego@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/sysdev/xive/common.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/arch/powerpc/sysdev/xive/common.c
++++ b/arch/powerpc/sysdev/xive/common.c
+@@ -479,7 +479,7 @@ static int xive_find_target_in_mask(cons
+ * Now go through the entire mask until we find a valid
+ * target.
+ */
+- for (;;) {
++ do {
+ /*
+ * We re-check online as the fallback case passes us
+ * an untested affinity mask
+@@ -487,12 +487,11 @@ static int xive_find_target_in_mask(cons
+ if (cpu_online(cpu) && xive_try_pick_target(cpu))
+ return cpu;
+ cpu = cpumask_next(cpu, mask);
+- if (cpu == first)
+- break;
+ /* Wrap around */
+ if (cpu >= nr_cpu_ids)
+ cpu = cpumask_first(mask);
+- }
++ } while (cpu != first);
++
+ return -1;
+ }
+
x86-sysfb_efi-add-quirks-for-some-devices-with-swapped-width-and-height.patch
x86-speculation-mds-apply-more-accurate-check-on-hypervisor-platform.patch
x86-stacktrace-prevent-access_ok-warnings-in-arch_stack_walk_user.patch
+binder-set-end-of-sg-buffer-area-properly.patch
+binder-prevent-transactions-to-context-manager-from-its-own-process.patch
+fpga-manager-altera-ps-spi-fix-build-error.patch
+mei-me-add-mule-creek-canyon-ehl-device-ids.patch
+eeprom-make-older-eeprom-drivers-select-nvmem_sysfs.patch
+hpet-fix-division-by-zero-in-hpet_time_div.patch
+drm-panel-add-support-for-armadeus-st0700-adapt.patch
+alsa-ac97-fix-double-free-of-ac97_codec_device.patch
+alsa-line6-fix-wrong-altsetting-for-line6_podhd500_1.patch
+alsa-pcm-fix-refcount_inc-on-zero-usage.patch
+alsa-hda-fix-intermittent-corb-rirb-stall-on-intel-chips.patch
+alsa-hda-add-a-conexant-codec-entry-to-let-mute-led-work.patch
+powerpc-dma-fix-invalid-dma-mmap-behavior.patch
+powerpc-xive-fix-loop-exit-condition-in-xive_find_target_in_mask.patch
+powerpc-mm-limit-rma_size-to-1tb-when-running-without-hv-mode.patch
+powerpc-tm-fix-oops-on-sigreturn-on-systems-without-tm.patch
+powerpc-pmu-set-pmcregs_in_use-in-paca-when-running-as-lpar.patch
+io_uring-fix-the-sequence-comparison-in-io_sequence_defer.patch
+iommu-vt-d-don-t-queue_iova-if-there-is-no-flush-queue.patch
+iommu-iova-remove-stale-cached32_node.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
