--- /dev/null
+From d288bddd8374e0a043ac9dde64a1ae6a09411d74 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Wed, 29 Jan 2020 14:40:06 +0100
+Subject: dmaengine: imx-sdma: fix context cache
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+commit d288bddd8374e0a043ac9dde64a1ae6a09411d74 upstream.
+
+There is a DMA problem with the serial ports on i.MX6.
+
+When the following sequence is performed:
+
+1) Open a port
+2) Write some data
+3) Close the port
+4) Open a *different* port
+5) Write some data
+6) Close the port
+
+The second write sends nothing and the second close hangs.
+If the first close() is omitted it works.
+
+Adding logs to the the UART driver shows that the DMA is being setup but
+the callback is never invoked for the second write.
+
+This used to work in 4.19.
+
+Git bisect leads to:
+ ad0d92d: "dmaengine: imx-sdma: refine to load context only once"
+
+This commit adds a "context_loaded" flag used to avoid unnecessary context
+setups.
+However the flag is only reset in sdma_channel_terminate_work(),
+which is only invoked in a worker triggered by sdma_terminate_all() IF
+there is an active descriptor.
+
+So, if no active descriptor remains when the channel is terminated, the
+flag is not reset and, when the channel is later reused the old context
+is used.
+
+Fix the problem by always resetting the flag in sdma_free_chan_resources().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://lore.kernel.org/r/1580305274-27274-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-sdma.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1335,6 +1335,7 @@ static void sdma_free_chan_resources(str
+
+ sdmac->event_id0 = 0;
+ sdmac->event_id1 = 0;
++ sdmac->context_loaded = false;
+
+ sdma_set_channel_priority(sdmac, 0);
+
--- /dev/null
+From 25962e1a7f1d522f1b57ead2f266fab570042a70 Mon Sep 17 00:00:00 2001
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+Date: Tue, 25 Feb 2020 08:23:20 +0000
+Subject: dmaengine: imx-sdma: Fix the event id check to include RX event for UART6
+
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+
+commit 25962e1a7f1d522f1b57ead2f266fab570042a70 upstream.
+
+On i.MX6UL/ULL and i.MX6SX the DMA event id for the RX channel of
+UART6 is '0'. To fix the broken DMA support for UART6, we change
+the check for event_id0 to include '0' as a valid id.
+
+Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
+Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200225082139.7646-1-frieder.schrempf@kontron.de
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-sdma.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1328,7 +1328,7 @@ static void sdma_free_chan_resources(str
+
+ sdma_channel_synchronize(chan);
+
+- if (sdmac->event_id0)
++ if (sdmac->event_id0 >= 0)
+ sdma_event_disable(sdmac, sdmac->event_id0);
+ if (sdmac->event_id1)
+ sdma_event_disable(sdmac, sdmac->event_id1);
+@@ -1629,7 +1629,7 @@ static int sdma_config(struct dma_chan *
+ memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
+
+ /* Set ENBLn earlier to make sure dma request triggered after that */
+- if (sdmac->event_id0) {
++ if (sdmac->event_id0 >= 0) {
+ if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
+ return -EINVAL;
+ sdma_event_enable(sdmac, sdmac->event_id0);
--- /dev/null
+From 80381d40c9bf5218db06a7d7246c5478c95987ee Mon Sep 17 00:00:00 2001
+From: Prike Liang <Prike.Liang@amd.com>
+Date: Mon, 2 Mar 2020 09:36:15 +0800
+Subject: drm/amd/powerplay: fix pre-check condition for setting clock range
+
+From: Prike Liang <Prike.Liang@amd.com>
+
+commit 80381d40c9bf5218db06a7d7246c5478c95987ee upstream.
+
+This fix will handle some MP1 FW issue like as mclk dpm table in renoir has a reverse
+dpm clock layout and a zero frequency dpm level as following case.
+
+cat pp_dpm_mclk
+0: 1200Mhz
+1: 1200Mhz
+2: 800Mhz
+3: 0Mhz
+
+Signed-off-by: Prike Liang <Prike.Liang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +-
+ drivers/gpu/drm/amd/powerplay/smu_v12_0.c | 3 ---
+ 2 files changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
++++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+@@ -222,7 +222,7 @@ int smu_set_soft_freq_range(struct smu_c
+ {
+ int ret = 0;
+
+- if (min <= 0 && max <= 0)
++ if (min < 0 && max < 0)
+ return -EINVAL;
+
+ if (!smu_clk_dpm_is_enabled(smu, clk_type))
+--- a/drivers/gpu/drm/amd/powerplay/smu_v12_0.c
++++ b/drivers/gpu/drm/amd/powerplay/smu_v12_0.c
+@@ -373,9 +373,6 @@ int smu_v12_0_set_soft_freq_limited_rang
+ {
+ int ret = 0;
+
+- if (max < min)
+- return -EINVAL;
+-
+ switch (clk_type) {
+ case SMU_GFXCLK:
+ case SMU_SCLK:
--- /dev/null
+From 194bcf35bce4a236059816bc41b3db9c9c92a1bb Mon Sep 17 00:00:00 2001
+From: "Tianci.Yin" <tianci.yin@amd.com>
+Date: Fri, 28 Feb 2020 17:10:21 +0800
+Subject: drm/amdgpu: disable 3D pipe 1 on Navi1x
+
+From: Tianci.Yin <tianci.yin@amd.com>
+
+commit 194bcf35bce4a236059816bc41b3db9c9c92a1bb upstream.
+
+[why]
+CP firmware decide to skip setting the state for 3D pipe 1 for Navi1x as there
+is no use case.
+
+[how]
+Disable 3D pipe 1 on Navi1x.
+
+Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
+Reviewed-by: Monk Liu <monk.liu@amd.com>
+Signed-off-by: Tianci.Yin <tianci.yin@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 95 +++++++++++++++++----------------
+ 1 file changed, 50 insertions(+), 45 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+@@ -54,7 +54,7 @@
+ * In bring-up phase, it just used primary ring so set gfx ring number as 1 at
+ * first.
+ */
+-#define GFX10_NUM_GFX_RINGS 2
++#define GFX10_NUM_GFX_RINGS_NV1X 1
+ #define GFX10_MEC_HPD_SIZE 2048
+
+ #define F32_CE_PROGRAM_RAM_SIZE 65536
+@@ -1286,7 +1286,7 @@ static int gfx_v10_0_sw_init(void *handl
+ case CHIP_NAVI14:
+ case CHIP_NAVI12:
+ adev->gfx.me.num_me = 1;
+- adev->gfx.me.num_pipe_per_me = 2;
++ adev->gfx.me.num_pipe_per_me = 1;
+ adev->gfx.me.num_queue_per_pipe = 1;
+ adev->gfx.mec.num_mec = 2;
+ adev->gfx.mec.num_pipe_per_mec = 4;
+@@ -2692,18 +2692,20 @@ static int gfx_v10_0_cp_gfx_start(struct
+ amdgpu_ring_commit(ring);
+
+ /* submit cs packet to copy state 0 to next available state */
+- ring = &adev->gfx.gfx_ring[1];
+- r = amdgpu_ring_alloc(ring, 2);
+- if (r) {
+- DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
+- return r;
+- }
+-
+- amdgpu_ring_write(ring, PACKET3(PACKET3_CLEAR_STATE, 0));
+- amdgpu_ring_write(ring, 0);
++ if (adev->gfx.num_gfx_rings > 1) {
++ /* maximum supported gfx ring is 2 */
++ ring = &adev->gfx.gfx_ring[1];
++ r = amdgpu_ring_alloc(ring, 2);
++ if (r) {
++ DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
++ return r;
++ }
+
+- amdgpu_ring_commit(ring);
++ amdgpu_ring_write(ring, PACKET3(PACKET3_CLEAR_STATE, 0));
++ amdgpu_ring_write(ring, 0);
+
++ amdgpu_ring_commit(ring);
++ }
+ return 0;
+ }
+
+@@ -2800,39 +2802,41 @@ static int gfx_v10_0_cp_gfx_resume(struc
+ mutex_unlock(&adev->srbm_mutex);
+
+ /* Init gfx ring 1 for pipe 1 */
+- mutex_lock(&adev->srbm_mutex);
+- gfx_v10_0_cp_gfx_switch_pipe(adev, PIPE_ID1);
+- ring = &adev->gfx.gfx_ring[1];
+- rb_bufsz = order_base_2(ring->ring_size / 8);
+- tmp = REG_SET_FIELD(0, CP_RB1_CNTL, RB_BUFSZ, rb_bufsz);
+- tmp = REG_SET_FIELD(tmp, CP_RB1_CNTL, RB_BLKSZ, rb_bufsz - 2);
+- WREG32_SOC15(GC, 0, mmCP_RB1_CNTL, tmp);
+- /* Initialize the ring buffer's write pointers */
+- ring->wptr = 0;
+- WREG32_SOC15(GC, 0, mmCP_RB1_WPTR, lower_32_bits(ring->wptr));
+- WREG32_SOC15(GC, 0, mmCP_RB1_WPTR_HI, upper_32_bits(ring->wptr));
+- /* Set the wb address wether it's enabled or not */
+- rptr_addr = adev->wb.gpu_addr + (ring->rptr_offs * 4);
+- WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR, lower_32_bits(rptr_addr));
+- WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR_HI, upper_32_bits(rptr_addr) &
+- CP_RB1_RPTR_ADDR_HI__RB_RPTR_ADDR_HI_MASK);
+- wptr_gpu_addr = adev->wb.gpu_addr + (ring->wptr_offs * 4);
+- WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_LO,
+- lower_32_bits(wptr_gpu_addr));
+- WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_HI,
+- upper_32_bits(wptr_gpu_addr));
+-
+- mdelay(1);
+- WREG32_SOC15(GC, 0, mmCP_RB1_CNTL, tmp);
+-
+- rb_addr = ring->gpu_addr >> 8;
+- WREG32_SOC15(GC, 0, mmCP_RB1_BASE, rb_addr);
+- WREG32_SOC15(GC, 0, mmCP_RB1_BASE_HI, upper_32_bits(rb_addr));
+- WREG32_SOC15(GC, 0, mmCP_RB1_ACTIVE, 1);
+-
+- gfx_v10_0_cp_gfx_set_doorbell(adev, ring);
+- mutex_unlock(&adev->srbm_mutex);
++ if (adev->gfx.num_gfx_rings > 1) {
++ mutex_lock(&adev->srbm_mutex);
++ gfx_v10_0_cp_gfx_switch_pipe(adev, PIPE_ID1);
++ /* maximum supported gfx ring is 2 */
++ ring = &adev->gfx.gfx_ring[1];
++ rb_bufsz = order_base_2(ring->ring_size / 8);
++ tmp = REG_SET_FIELD(0, CP_RB1_CNTL, RB_BUFSZ, rb_bufsz);
++ tmp = REG_SET_FIELD(tmp, CP_RB1_CNTL, RB_BLKSZ, rb_bufsz - 2);
++ WREG32_SOC15(GC, 0, mmCP_RB1_CNTL, tmp);
++ /* Initialize the ring buffer's write pointers */
++ ring->wptr = 0;
++ WREG32_SOC15(GC, 0, mmCP_RB1_WPTR, lower_32_bits(ring->wptr));
++ WREG32_SOC15(GC, 0, mmCP_RB1_WPTR_HI, upper_32_bits(ring->wptr));
++ /* Set the wb address wether it's enabled or not */
++ rptr_addr = adev->wb.gpu_addr + (ring->rptr_offs * 4);
++ WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR, lower_32_bits(rptr_addr));
++ WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR_HI, upper_32_bits(rptr_addr) &
++ CP_RB1_RPTR_ADDR_HI__RB_RPTR_ADDR_HI_MASK);
++ wptr_gpu_addr = adev->wb.gpu_addr + (ring->wptr_offs * 4);
++ WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_LO,
++ lower_32_bits(wptr_gpu_addr));
++ WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_HI,
++ upper_32_bits(wptr_gpu_addr));
++
++ mdelay(1);
++ WREG32_SOC15(GC, 0, mmCP_RB1_CNTL, tmp);
++
++ rb_addr = ring->gpu_addr >> 8;
++ WREG32_SOC15(GC, 0, mmCP_RB1_BASE, rb_addr);
++ WREG32_SOC15(GC, 0, mmCP_RB1_BASE_HI, upper_32_bits(rb_addr));
++ WREG32_SOC15(GC, 0, mmCP_RB1_ACTIVE, 1);
+
++ gfx_v10_0_cp_gfx_set_doorbell(adev, ring);
++ mutex_unlock(&adev->srbm_mutex);
++ }
+ /* Switch to pipe 0 */
+ mutex_lock(&adev->srbm_mutex);
+ gfx_v10_0_cp_gfx_switch_pipe(adev, PIPE_ID0);
+@@ -3952,7 +3956,8 @@ static int gfx_v10_0_early_init(void *ha
+ {
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+- adev->gfx.num_gfx_rings = GFX10_NUM_GFX_RINGS;
++ adev->gfx.num_gfx_rings = GFX10_NUM_GFX_RINGS_NV1X;
++
+ adev->gfx.num_compute_rings = AMDGPU_MAX_COMPUTE_RINGS;
+
+ gfx_v10_0_set_kiq_pm4_funcs(adev);
--- /dev/null
+From 1cad629257e76025bcbf490c58de550fb67d4d0e Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann <kraxel@redhat.com>
+Date: Wed, 26 Feb 2020 16:47:50 +0100
+Subject: drm/shmem: add support for per object caching flags.
+
+From: Gerd Hoffmann <kraxel@redhat.com>
+
+commit 1cad629257e76025bcbf490c58de550fb67d4d0e upstream.
+
+Add map_cached bool to drm_gem_shmem_object, to request cached mappings
+on a per-object base. Check the flag before adding writecombine to
+pgprot bits.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
+Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-2-kraxel@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_gem_shmem_helper.c | 15 +++++++++++----
+ include/drm/drm_gem_shmem_helper.h | 5 +++++
+ 2 files changed, 16 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
++++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
+@@ -254,11 +254,16 @@ static void *drm_gem_shmem_vmap_locked(s
+ if (ret)
+ goto err_zero_use;
+
+- if (obj->import_attach)
++ if (obj->import_attach) {
+ shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
+- else
++ } else {
++ pgprot_t prot = PAGE_KERNEL;
++
++ if (!shmem->map_cached)
++ prot = pgprot_writecombine(prot);
+ shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
+- VM_MAP, pgprot_writecombine(PAGE_KERNEL));
++ VM_MAP, prot);
++ }
+
+ if (!shmem->vaddr) {
+ DRM_DEBUG_KMS("Failed to vmap pages\n");
+@@ -537,7 +542,9 @@ int drm_gem_shmem_mmap(struct drm_gem_ob
+ }
+
+ vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
+- vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
++ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
++ if (!shmem->map_cached)
++ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ vma->vm_ops = &drm_gem_shmem_vm_ops;
+
+--- a/include/drm/drm_gem_shmem_helper.h
++++ b/include/drm/drm_gem_shmem_helper.h
+@@ -96,6 +96,11 @@ struct drm_gem_shmem_object {
+ * The address are un-mapped when the count reaches zero.
+ */
+ unsigned int vmap_use_count;
++
++ /**
++ * @map_cached: map object cached (instead of using writecombine).
++ */
++ bool map_cached;
+ };
+
+ #define to_drm_gem_shmem_obj(obj) \
--- /dev/null
+From 6be7e07335486f5731cab748d80c68f20896581f Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann <kraxel@redhat.com>
+Date: Wed, 26 Feb 2020 16:47:51 +0100
+Subject: drm/virtio: fix mmap page attributes
+
+From: Gerd Hoffmann <kraxel@redhat.com>
+
+commit 6be7e07335486f5731cab748d80c68f20896581f upstream.
+
+virtio-gpu uses cached mappings, set
+drm_gem_shmem_object.map_cached accordingly.
+
+Cc: stable@vger.kernel.org
+Fixes: c66df701e783 ("drm/virtio: switch from ttm to gem shmem helpers")
+Reported-by: Gurchetan Singh <gurchetansingh@chromium.org>
+Reported-by: Guillaume Gardet <Guillaume.Gardet@arm.com>
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
+Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-3-kraxel@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/virtio/virtgpu_object.c
++++ b/drivers/gpu/drm/virtio/virtgpu_object.c
+@@ -99,6 +99,7 @@ struct drm_gem_object *virtio_gpu_create
+ return NULL;
+
+ bo->base.base.funcs = &virtio_gpu_gem_funcs;
++ bo->base.map_cached = true;
+ return &bo->base.base;
+ }
+
--- /dev/null
+From d171c45da874e3858a83e6377e00280a507fe2f2 Mon Sep 17 00:00:00 2001
+From: Ezequiel Garcia <ezequiel@collabora.com>
+Date: Tue, 4 Feb 2020 20:38:37 +0100
+Subject: media: hantro: Fix broken media controller links
+
+From: Ezequiel Garcia <ezequiel@collabora.com>
+
+commit d171c45da874e3858a83e6377e00280a507fe2f2 upstream.
+
+The driver currently creates a broken topology,
+with a source-to-source link and a sink-to-sink
+link instead of two source-to-sink links.
+
+Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
+Cc: <stable@vger.kernel.org> # for v5.3 and up
+Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
+Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/media/hantro/hantro_drv.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/staging/media/hantro/hantro_drv.c
++++ b/drivers/staging/media/hantro/hantro_drv.c
+@@ -553,13 +553,13 @@ static int hantro_attach_func(struct han
+ goto err_rel_entity1;
+
+ /* Connect the three entities */
+- ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 1,
++ ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rel_entity2;
+
+- ret = media_create_pad_link(&func->proc, 0, &func->sink, 0,
++ ret = media_create_pad_link(&func->proc, 1, &func->sink, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
--- /dev/null
+From 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 19:19:22 +0100
+Subject: media: mc-entity.c: use & to check pad flags, not ==
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 upstream.
+
+These are bits so to test if a pad is a sink you use & but not ==.
+
+It looks like the only reason this hasn't caused problems before is that
+media_get_pad_index() is currently only used with pads that do not set the
+MEDIA_PAD_FL_MUST_CONNECT flag. So a pad really had only the SINK or SOURCE
+flag set and nothing else.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v5.3 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/mc/mc-entity.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/mc/mc-entity.c
++++ b/drivers/media/mc/mc-entity.c
+@@ -639,9 +639,9 @@ int media_get_pad_index(struct media_ent
+ return -EINVAL;
+
+ for (i = 0; i < entity->num_pads; i++) {
+- if (entity->pads[i].flags == MEDIA_PAD_FL_SINK)
++ if (entity->pads[i].flags & MEDIA_PAD_FL_SINK)
+ pad_is_sink = true;
+- else if (entity->pads[i].flags == MEDIA_PAD_FL_SOURCE)
++ else if (entity->pads[i].flags & MEDIA_PAD_FL_SOURCE)
+ pad_is_sink = false;
+ else
+ continue; /* This is an error! */
--- /dev/null
+From 316e730f1d8bb029fe6cec2468fb2a50424485b3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 19:13:06 +0100
+Subject: media: v4l2-mem2mem.c: fix broken links
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 316e730f1d8bb029fe6cec2468fb2a50424485b3 upstream.
+
+The topology that v4l2_m2m_register_media_controller() creates for a
+processing block actually created a source-to-source link and a sink-to-sink
+link instead of two source-to-sink links.
+
+Unfortunately v4l2-compliance never checked for such bad links, so this
+went unreported for quite some time.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
+Cc: <stable@vger.kernel.org> # for v4.19 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/v4l2-mem2mem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
++++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
+@@ -880,12 +880,12 @@ int v4l2_m2m_register_media_controller(s
+ goto err_rel_entity1;
+
+ /* Connect the three entities */
+- ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 1,
++ ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rel_entity2;
+
+- ret = media_create_pad_link(&m2m_dev->proc, 0, &m2m_dev->sink, 0,
++ ret = media_create_pad_link(&m2m_dev->proc, 1, &m2m_dev->sink, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rm_links0;
--- /dev/null
+From 49a56266f96f2c6608373464af8755b431ef1513 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 13:45:04 +0100
+Subject: media: vicodec: process all 4 components for RGB32 formats
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 49a56266f96f2c6608373464af8755b431ef1513 upstream.
+
+Only ARGB32-type pixelformat were assumed to have 4 components, which is
+wrong since RGB32-type pixelformats may have an alpha channel, so they
+should also assume 4 color components.
+
+The XRGB32-type pixelformats really have only 3 color components, but this
+complicated matters since that creates strides that are sometimes width * 3
+and sometimes width * 4, and in fact this can result in buffer overflows.
+
+Keep things simple by just always processing all 4 color components.
+
+In the future we might want to optimize this again for the XRGB32-type
+pixelformats, but for now keep it simple and robust.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v5.4 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vicodec/codec-v4l2-fwht.c | 34 ++++++-----------------
+ 1 file changed, 9 insertions(+), 25 deletions(-)
+
+--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
++++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
+@@ -27,17 +27,17 @@ static const struct v4l2_fwht_pixfmt_inf
+ { V4L2_PIX_FMT_BGR24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_RGB24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_HSV24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV},
+- { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_ABGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_ARGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_BGRA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_RGBA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV},
++ { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_HSV},
+ { V4L2_PIX_FMT_GREY, 1, 1, 1, 1, 0, 1, 1, 1, 1, FWHT_FL_PIXENC_RGB},
+ };
+
+@@ -175,22 +175,14 @@ static int prepare_raw_frame(struct fwht
+ case V4L2_PIX_FMT_RGB32:
+ case V4L2_PIX_FMT_XRGB32:
+ case V4L2_PIX_FMT_HSV32:
+- rf->cr = rf->luma + 1;
+- rf->cb = rf->cr + 2;
+- rf->luma += 2;
+- break;
+- case V4L2_PIX_FMT_BGR32:
+- case V4L2_PIX_FMT_XBGR32:
+- rf->cb = rf->luma;
+- rf->cr = rf->cb + 2;
+- rf->luma++;
+- break;
+ case V4L2_PIX_FMT_ARGB32:
+ rf->alpha = rf->luma;
+ rf->cr = rf->luma + 1;
+ rf->cb = rf->cr + 2;
+ rf->luma += 2;
+ break;
++ case V4L2_PIX_FMT_BGR32:
++ case V4L2_PIX_FMT_XBGR32:
+ case V4L2_PIX_FMT_ABGR32:
+ rf->cb = rf->luma;
+ rf->cr = rf->cb + 2;
+@@ -198,10 +190,6 @@ static int prepare_raw_frame(struct fwht
+ rf->alpha = rf->cr + 1;
+ break;
+ case V4L2_PIX_FMT_BGRX32:
+- rf->cb = rf->luma + 1;
+- rf->cr = rf->cb + 2;
+- rf->luma += 2;
+- break;
+ case V4L2_PIX_FMT_BGRA32:
+ rf->alpha = rf->luma;
+ rf->cb = rf->luma + 1;
+@@ -209,10 +197,6 @@ static int prepare_raw_frame(struct fwht
+ rf->luma += 2;
+ break;
+ case V4L2_PIX_FMT_RGBX32:
+- rf->cr = rf->luma;
+- rf->cb = rf->cr + 2;
+- rf->luma++;
+- break;
+ case V4L2_PIX_FMT_RGBA32:
+ rf->alpha = rf->luma + 3;
+ rf->cr = rf->luma;
--- /dev/null
+From d6bc34c5ec18c3544c4b0d85963768dfbcd24184 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 14 Feb 2020 15:26:53 +0200
+Subject: perf arm-spe: Fix endless record after being terminated
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit d6bc34c5ec18c3544c4b0d85963768dfbcd24184 upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the event is disabled, don't enable it again here.
+
+Based-on-patch-by: Wei Li <liwei391@huawei.com>
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-5-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/arm64/util/arm-spe.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/arm64/util/arm-spe.c
++++ b/tools/perf/arch/arm64/util/arm-spe.c
+@@ -165,9 +165,12 @@ static int arm_spe_read_finish(struct au
+ struct evsel *evsel;
+
+ evlist__for_each_entry(sper->evlist, evsel) {
+- if (evsel->core.attr.type == sper->arm_spe_pmu->type)
++ if (evsel->core.attr.type == sper->arm_spe_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(sper->evlist,
+ evsel, idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:52 +0200
+Subject: perf cs-etm: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the cs_etm event is disabled, we don't enable it again here.
+
+Note: This patch is NOT tested since i don't have such a machine with
+coresight feature, but the code seems buggy same as arm-spe and
+intel-pt.
+
+Tester notes:
+
+Thanks for looping, Adrian. Applied this patch and tested with
+CoreSight on juno board, it works well.
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Reviewed-by: Leo Yan <leo.yan@linaro.org>
+Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Tested-by: Leo Yan <leo.yan@linaro.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-4-adrian.hunter@intel.com
+[ahunter: removed redundant 'else' after 'return']
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/arm/util/cs-etm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/arm/util/cs-etm.c
++++ b/tools/perf/arch/arm/util/cs-etm.c
+@@ -865,9 +865,12 @@ static int cs_etm_read_finish(struct aux
+ struct evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+- if (evsel->core.attr.type == ptr->cs_etm_pmu->type)
++ if (evsel->core.attr.type == ptr->cs_etm_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(ptr->evlist,
+ evsel, idx);
++ }
+ }
+
+ return -EINVAL;
--- /dev/null
+From 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:51 +0200
+Subject: perf intel-bts: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the intel_bts event is disabled, we don't enable it again here.
+
+Note: This patch is NOT tested since i don't have such a machine with
+intel_bts feature, but the code seems buggy same as arm-spe and
+intel-pt.
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-3-adrian.hunter@intel.com
+[ahunter: removed redundant 'else' after 'return']
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/x86/util/intel-bts.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/x86/util/intel-bts.c
++++ b/tools/perf/arch/x86/util/intel-bts.c
+@@ -420,9 +420,12 @@ static int intel_bts_read_finish(struct
+ struct evsel *evsel;
+
+ evlist__for_each_entry(btsr->evlist, evsel) {
+- if (evsel->core.attr.type == btsr->intel_bts_pmu->type)
++ if (evsel->core.attr.type == btsr->intel_bts_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(btsr->evlist,
+ evsel, idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:50 +0200
+Subject: perf intel-pt: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be endless.
+
+If the intel_pt event is disabled, we don't enable it again here.
+
+Before the patch:
+
+ huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \
+ intel_pt//u -p 46803
+ ^C^C^C^C^C^C
+
+After the patch:
+
+ huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \
+ intel_pt//u -p 48591
+ ^C[ perf record: Woken up 0 times to write data ]
+ Warning:
+ AUX data lost 504 times out of 4816!
+
+ [ perf record: Captured and wrote 2024.405 MB perf.data ]
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-2-adrian.hunter@intel.com
+[ ahunter: removed redundant 'else' after 'return' ]
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/x86/util/intel-pt.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/x86/util/intel-pt.c
++++ b/tools/perf/arch/x86/util/intel-pt.c
+@@ -1173,9 +1173,12 @@ static int intel_pt_read_finish(struct a
+ struct evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+- if (evsel->core.attr.type == ptr->intel_pt_pmu->type)
++ if (evsel->core.attr.type == ptr->intel_pt_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(ptr->evlist, evsel,
+ idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From 59bee45b9712c759ea4d3dcc4eff1752f3a66558 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Tue, 3 Mar 2020 23:28:47 +1100
+Subject: powerpc/mm: Fix missing KUAP disable in flush_coherent_icache()
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+commit 59bee45b9712c759ea4d3dcc4eff1752f3a66558 upstream.
+
+Stefan reported a strange kernel fault which turned out to be due to a
+missing KUAP disable in flush_coherent_icache() called from
+flush_icache_range().
+
+The fault looks like:
+
+ Kernel attempted to access user page (7fffc30d9c00) - exploit attempt? (uid: 1009)
+ BUG: Unable to handle kernel data access on read at 0x7fffc30d9c00
+ Faulting instruction address: 0xc00000000007232c
+ Oops: Kernel access of bad area, sig: 11 [#1]
+ LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
+ CPU: 35 PID: 5886 Comm: sigtramp Not tainted 5.6.0-rc2-gcc-8.2.0-00003-gfc37a1632d40 #79
+ NIP: c00000000007232c LR: c00000000003b7fc CTR: 0000000000000000
+ REGS: c000001e11093940 TRAP: 0300 Not tainted (5.6.0-rc2-gcc-8.2.0-00003-gfc37a1632d40)
+ MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000884 XER: 00000000
+ CFAR: c0000000000722fc DAR: 00007fffc30d9c00 DSISR: 08000000 IRQMASK: 0
+ GPR00: c00000000003b7fc c000001e11093bd0 c0000000023ac200 00007fffc30d9c00
+ GPR04: 00007fffc30d9c18 0000000000000000 c000001e11093bd4 0000000000000000
+ GPR08: 0000000000000000 0000000000000001 0000000000000000 c000001e1104ed80
+ GPR12: 0000000000000000 c000001fff6ab380 c0000000016be2d0 4000000000000000
+ GPR16: c000000000000000 bfffffffffffffff 0000000000000000 0000000000000000
+ GPR20: 00007fffc30d9c00 00007fffc30d8f58 00007fffc30d9c18 00007fffc30d9c20
+ GPR24: 00007fffc30d9c18 0000000000000000 c000001e11093d90 c000001e1104ed80
+ GPR28: c000001e11093e90 0000000000000000 c0000000023d9d18 00007fffc30d9c00
+ NIP flush_icache_range+0x5c/0x80
+ LR handle_rt_signal64+0x95c/0xc2c
+ Call Trace:
+ 0xc000001e11093d90 (unreliable)
+ handle_rt_signal64+0x93c/0xc2c
+ do_notify_resume+0x310/0x430
+ ret_from_except_lite+0x70/0x74
+ Instruction dump:
+ 409e002c 7c0802a6 3c62ff31 3863f6a0 f8010080 48195fed 60000000 48fe4c8d
+ 60000000 e8010080 7c0803a6 7c0004ac <7c00ffac> 7c0004ac 4c00012c 38210070
+
+This path through handle_rt_signal64() to setup_trampoline() and
+flush_icache_range() is only triggered by 64-bit processes that have
+unmapped their VDSO, which is rare.
+
+flush_icache_range() takes a range of addresses to flush. In
+flush_coherent_icache() we implement an optimisation for CPUs where we
+know we don't actually have to flush the whole range, we just need to
+do a single icbi.
+
+However we still execute the icbi on the user address of the start of
+the range we're flushing. On CPUs that also implement KUAP (Power9)
+that leads to the spurious fault above.
+
+We should be able to pass any address, including a kernel address, to
+the icbi on these CPUs, which would avoid any interaction with KUAP.
+But I don't want to make that change in a bug fix, just in case it
+surfaces some strange behaviour on some CPU.
+
+So for now just disable KUAP around the icbi. Note the icbi is treated
+as a load, so we allow read access, not write as you'd expect.
+
+Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
+Cc: stable@vger.kernel.org # v5.2+
+Reported-by: Stefan Berger <stefanb@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200303235708.26004-1-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/mm/mem.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/mm/mem.c
++++ b/arch/powerpc/mm/mem.c
+@@ -369,7 +369,9 @@ static inline bool flush_coherent_icache
+ */
+ if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) {
+ mb(); /* sync */
++ allow_read_from_user((const void __user *)addr, L1_CACHE_BYTES);
+ icbi((void *)addr);
++ prevent_read_from_user((const void __user *)addr, L1_CACHE_BYTES);
+ mb(); /* sync */
+ isync();
+ return true;
--- /dev/null
+From 582b4e55403e053d8a48ff687a05174da9cc3fb0 Mon Sep 17 00:00:00 2001
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Date: Thu, 27 Feb 2020 12:56:42 +0100
+Subject: s390/mm: fix panic in gup_fast on large pud
+
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+
+commit 582b4e55403e053d8a48ff687a05174da9cc3fb0 upstream.
+
+On s390 there currently is no implementation of pud_write(). That was ok
+as long as we had our own implementation of get_user_pages_fast() which
+checked for pud protection by testing the bit directly w/o using
+pud_write(). The other callers of pud_write() are not reachable on s390.
+
+After commit 1a42010cdc26 ("s390/mm: convert to the generic
+get_user_pages_fast code") we use the generic get_user_pages_fast(), which
+does call pud_write() in pud_access_permitted() for FOLL_WRITE access on
+a large pud. Without an s390 specific pud_write(), the generic version is
+called, which contains a BUG() statement to remind us that we don't have a
+proper implementation. This results in a kernel panic.
+
+Fix this by providing an implementation of pud_write().
+
+Cc: <stable@vger.kernel.org> # 5.2+
+Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
+Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/include/asm/pgtable.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/s390/include/asm/pgtable.h
++++ b/arch/s390/include/asm/pgtable.h
+@@ -750,6 +750,12 @@ static inline int pmd_write(pmd_t pmd)
+ return (pmd_val(pmd) & _SEGMENT_ENTRY_WRITE) != 0;
+ }
+
++#define pud_write pud_write
++static inline int pud_write(pud_t pud)
++{
++ return (pud_val(pud) & _REGION3_ENTRY_WRITE) != 0;
++}
++
+ static inline int pmd_dirty(pmd_t pmd)
+ {
+ return (pmd_val(pmd) & _SEGMENT_ENTRY_DIRTY) != 0;
--- /dev/null
+From df057c914a9c219ac8b8ed22caf7da2f80c1fe26 Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Thu, 27 Feb 2020 12:17:18 +0100
+Subject: s390/pci: Fix unexpected write combine on resource
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+commit df057c914a9c219ac8b8ed22caf7da2f80c1fe26 upstream.
+
+In the initial MIO support introduced in
+
+commit 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions")
+
+zpci_map_resource() and zpci_setup_resources() default to using the
+mio_wb address as the resource's start address. This means users of the
+mapping, which includes most drivers, will get write combining on PCI
+Stores. This may lead to problems when drivers expect write through
+behavior when not using an explicit ioremap_wc().
+
+Cc: stable@vger.kernel.org
+Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions")
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/pci/pci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/pci/pci.c
++++ b/arch/s390/pci/pci.c
+@@ -424,7 +424,7 @@ static void zpci_map_resources(struct pc
+
+ if (zpci_use_mio(zdev))
+ pdev->resource[i].start =
+- (resource_size_t __force) zdev->bars[i].mio_wb;
++ (resource_size_t __force) zdev->bars[i].mio_wt;
+ else
+ pdev->resource[i].start = (resource_size_t __force)
+ pci_iomap_range_fh(pdev, i, 0, 0);
+@@ -531,7 +531,7 @@ static int zpci_setup_bus_resources(stru
+ flags |= IORESOURCE_MEM_64;
+
+ if (zpci_use_mio(zdev))
+- addr = (unsigned long) zdev->bars[i].mio_wb;
++ addr = (unsigned long) zdev->bars[i].mio_wt;
+ else
+ addr = ZPCI_ADDR(entry);
+ size = 1UL << zdev->bars[i].size;
--- /dev/null
+From 186e28a18aeb0fec99cc586fda337e6b23190791 Mon Sep 17 00:00:00 2001
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Fri, 28 Feb 2020 00:00:08 +0000
+Subject: selftests: pidfd: Add pidfd_fdinfo_test in .gitignore
+
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+
+commit 186e28a18aeb0fec99cc586fda337e6b23190791 upstream.
+
+The commit identified below added pidfd_fdinfo_test
+but failed to add it to .gitignore
+
+Fixes: 2def297ec7fb ("pidfd: add tests for NSpid info in fdinfo")
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/966567c7dbaa26a06730d796354f8a086c0ee288.1582847778.git.christophe.leroy@c-s.fr
+Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/testing/selftests/pidfd/.gitignore | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/testing/selftests/pidfd/.gitignore
++++ b/tools/testing/selftests/pidfd/.gitignore
+@@ -2,3 +2,4 @@ pidfd_open_test
+ pidfd_poll_test
+ pidfd_test
+ pidfd_wait
++pidfd_fdinfo_test
serdev-fix-detection-of-uart-devices-on-apple-machines.patch
vt-selection-close-sel_buffer-race.patch
vt-selection-push-console-lock-down.patch
+vt-selection-push-sel_lock-up.patch
+media-hantro-fix-broken-media-controller-links.patch
+media-mc-entity.c-use-to-check-pad-flags-not.patch
+media-vicodec-process-all-4-components-for-rgb32-formats.patch
+media-v4l2-mem2mem.c-fix-broken-links.patch
+perf-intel-pt-fix-endless-record-after-being-terminated.patch
+perf-intel-bts-fix-endless-record-after-being-terminated.patch
+perf-cs-etm-fix-endless-record-after-being-terminated.patch
+perf-arm-spe-fix-endless-record-after-being-terminated.patch
+spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch
+x86-ioperm-add-new-paravirt-function-update_io_bitmap.patch
+x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch
+s390-pci-fix-unexpected-write-combine-on-resource.patch
+s390-mm-fix-panic-in-gup_fast-on-large-pud.patch
+selftests-pidfd-add-pidfd_fdinfo_test-in-.gitignore.patch
+powerpc-mm-fix-missing-kuap-disable-in-flush_coherent_icache.patch
+drm-virtio-fix-mmap-page-attributes.patch
+drm-shmem-add-support-for-per-object-caching-flags.patch
+drm-amdgpu-disable-3d-pipe-1-on-navi1x.patch
+drm-amd-powerplay-fix-pre-check-condition-for-setting-clock-range.patch
+dmaengine-imx-sdma-fix-context-cache.patch
+dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch
--- /dev/null
+From 138c9c32f090894614899eca15e0bb7279f59865 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Tue, 18 Feb 2020 13:08:00 +0100
+Subject: spi: spidev: Fix CS polarity if GPIO descriptors are used
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 138c9c32f090894614899eca15e0bb7279f59865 upstream.
+
+Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
+amended of_spi_parse_dt() to always set SPI_CS_HIGH for SPI slaves whose
+Chip Select is defined by a "cs-gpios" devicetree property.
+
+This change broke userspace applications which issue an SPI_IOC_WR_MODE
+ioctl() to an spidev: Chip Select polarity will be incorrect unless the
+application is changed to set SPI_CS_HIGH. And once changed, it will be
+incompatible with kernels not containing the commit.
+
+Fix by setting SPI_CS_HIGH in spidev_ioctl() (under the same conditions
+as in of_spi_parse_dt()).
+
+Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
+Reported-by: Simon Han <z.han@kunbus.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas@wunner.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org # v5.1+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spidev.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/spi/spidev.c
++++ b/drivers/spi/spidev.c
+@@ -396,6 +396,7 @@ spidev_ioctl(struct file *filp, unsigned
+ else
+ retval = get_user(tmp, (u32 __user *)arg);
+ if (retval == 0) {
++ struct spi_controller *ctlr = spi->controller;
+ u32 save = spi->mode;
+
+ if (tmp & ~SPI_MODE_MASK) {
+@@ -403,6 +404,10 @@ spidev_ioctl(struct file *filp, unsigned
+ break;
+ }
+
++ if (ctlr->use_gpio_descriptors && ctlr->cs_gpiods &&
++ ctlr->cs_gpiods[spi->chip_select])
++ tmp |= SPI_CS_HIGH;
++
+ tmp |= spi->mode & ~SPI_MODE_MASK;
+ spi->mode = (u16)tmp;
+ retval = spi_setup(spi);
--- /dev/null
+From e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri, 28 Feb 2020 12:54:06 +0100
+Subject: vt: selection, push sel_lock up
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 upstream.
+
+sel_lock cannot nest in the console lock. Thanks to syzkaller, the
+kernel states firmly:
+
+> WARNING: possible circular locking dependency detected
+> 5.6.0-rc3-syzkaller #0 Not tainted
+> ------------------------------------------------------
+> syz-executor.4/20336 is trying to acquire lock:
+> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+>
+> but task is already holding lock:
+> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
+>
+> which lock already depends on the new lock.
+>
+> the existing dependency chain (in reverse order) is:
+>
+> -> #2 (sel_lock){+.+.}:
+> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
+> set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
+> set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
+> tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_SETSEL).
+Locks held on the path: console_lock -> sel_lock
+
+> -> #1 (console_lock){+.+.}:
+> console_lock+0x46/0x70 kernel/printk/printk.c:2289
+> con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
+> n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
+> do_tty_write drivers/tty/tty_io.c:962 [inline]
+> tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
+
+This is write().
+Locks held on the path: termios_rwsem -> console_lock
+
+> -> #0 (&tty->termios_rwsem){++++}:
+> down_write+0x57/0x140 kernel/locking/rwsem.c:1534
+> tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+> mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
+> tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
+> paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
+> tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_PASTESEL).
+Locks held on the path: sel_lock -> termios_rwsem
+
+> other info that might help us debug this:
+>
+> Chain exists of:
+> &tty->termios_rwsem --> console_lock --> sel_lock
+
+Clearly. From the above, we have:
+ console_lock -> sel_lock
+ sel_lock -> termios_rwsem
+ termios_rwsem -> console_lock
+
+Fix this by reversing the console_lock -> sel_lock dependency in
+ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
+Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/selection.c | 16 +++++++---------
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/drivers/tty/vt/selection.c
++++ b/drivers/tty/vt/selection.c
+@@ -214,7 +214,6 @@ static int __set_selection_kernel(struct
+ if (ps > pe) /* make sel_start <= sel_end */
+ swap(ps, pe);
+
+- mutex_lock(&sel_lock);
+ if (sel_cons != vc_cons[fg_console].d) {
+ clear_selection();
+ sel_cons = vc_cons[fg_console].d;
+@@ -260,10 +259,9 @@ static int __set_selection_kernel(struct
+ break;
+ case TIOCL_SELPOINTER:
+ highlight_pointer(pe);
+- goto unlock;
++ return 0;
+ default:
+- ret = -EINVAL;
+- goto unlock;
++ return -EINVAL;
+ }
+
+ /* remove the pointer */
+@@ -285,7 +283,7 @@ static int __set_selection_kernel(struct
+ else if (new_sel_start == sel_start)
+ {
+ if (new_sel_end == sel_end) /* no action required */
+- goto unlock;
++ return 0;
+ else if (new_sel_end > sel_end) /* extend to right */
+ highlight(sel_end + 2, new_sel_end);
+ else /* contract from right */
+@@ -313,8 +311,7 @@ static int __set_selection_kernel(struct
+ if (!bp) {
+ printk(KERN_WARNING "selection: kmalloc() failed\n");
+ clear_selection();
+- ret = -ENOMEM;
+- goto unlock;
++ return -ENOMEM;
+ }
+ kfree(sel_buffer);
+ sel_buffer = bp;
+@@ -339,8 +336,7 @@ static int __set_selection_kernel(struct
+ }
+ }
+ sel_buffer_lth = bp - sel_buffer;
+-unlock:
+- mutex_unlock(&sel_lock);
++
+ return ret;
+ }
+
+@@ -348,9 +344,11 @@ int set_selection_kernel(struct tiocl_se
+ {
+ int ret;
+
++ mutex_lock(&sel_lock);
+ console_lock();
+ ret = __set_selection_kernel(v, tty);
+ console_unlock();
++ mutex_unlock(&sel_lock);
+
+ return ret;
+ }
--- /dev/null
+From 99bcd4a6e5b8ba201fdd252f1054689884899fee Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Tue, 18 Feb 2020 16:47:12 +0100
+Subject: x86/ioperm: Add new paravirt function update_io_bitmap()
+
+From: Juergen Gross <jgross@suse.com>
+
+commit 99bcd4a6e5b8ba201fdd252f1054689884899fee upstream.
+
+Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm()
+as well") reworked the iopl syscall to use I/O bitmaps.
+
+Unfortunately this broke Xen PV domains using that syscall as there is
+currently no I/O bitmap support in PV domains.
+
+Add I/O bitmap support via a new paravirt function update_io_bitmap which
+Xen PV domains can use to update their I/O bitmaps via a hypercall.
+
+Fixes: 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well")
+Reported-by: Jan Beulich <jbeulich@suse.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Jan Beulich <jbeulich@suse.com>
+Reviewed-by: Jan Beulich <jbeulich@suse.com>
+Cc: <stable@vger.kernel.org> # 5.5
+Link: https://lkml.kernel.org/r/20200218154712.25490-1-jgross@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/io_bitmap.h | 9 ++++++++-
+ arch/x86/include/asm/paravirt.h | 7 +++++++
+ arch/x86/include/asm/paravirt_types.h | 4 ++++
+ arch/x86/kernel/paravirt.c | 5 +++++
+ arch/x86/kernel/process.c | 2 +-
+ arch/x86/xen/enlighten_pv.c | 25 +++++++++++++++++++++++++
+ 6 files changed, 50 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/include/asm/io_bitmap.h
++++ b/arch/x86/include/asm/io_bitmap.h
+@@ -19,7 +19,14 @@ struct task_struct;
+ void io_bitmap_share(struct task_struct *tsk);
+ void io_bitmap_exit(void);
+
+-void tss_update_io_bitmap(void);
++void native_tss_update_io_bitmap(void);
++
++#ifdef CONFIG_PARAVIRT_XXL
++#include <asm/paravirt.h>
++#else
++#define tss_update_io_bitmap native_tss_update_io_bitmap
++#endif
++
+ #else
+ static inline void io_bitmap_share(struct task_struct *tsk) { }
+ static inline void io_bitmap_exit(void) { }
+--- a/arch/x86/include/asm/paravirt.h
++++ b/arch/x86/include/asm/paravirt.h
+@@ -295,6 +295,13 @@ static inline void write_idt_entry(gate_
+ PVOP_VCALL3(cpu.write_idt_entry, dt, entry, g);
+ }
+
++#ifdef CONFIG_X86_IOPL_IOPERM
++static inline void tss_update_io_bitmap(void)
++{
++ PVOP_VCALL0(cpu.update_io_bitmap);
++}
++#endif
++
+ static inline void paravirt_activate_mm(struct mm_struct *prev,
+ struct mm_struct *next)
+ {
+--- a/arch/x86/include/asm/paravirt_types.h
++++ b/arch/x86/include/asm/paravirt_types.h
+@@ -140,6 +140,10 @@ struct pv_cpu_ops {
+
+ void (*load_sp0)(unsigned long sp0);
+
++#ifdef CONFIG_X86_IOPL_IOPERM
++ void (*update_io_bitmap)(void);
++#endif
++
+ void (*wbinvd)(void);
+
+ /* cpuid emulation, mostly so that caps bits can be disabled */
+--- a/arch/x86/kernel/paravirt.c
++++ b/arch/x86/kernel/paravirt.c
+@@ -30,6 +30,7 @@
+ #include <asm/timer.h>
+ #include <asm/special_insns.h>
+ #include <asm/tlb.h>
++#include <asm/io_bitmap.h>
+
+ /*
+ * nop stub, which must not clobber anything *including the stack* to
+@@ -341,6 +342,10 @@ struct paravirt_patch_template pv_ops =
+ .cpu.iret = native_iret,
+ .cpu.swapgs = native_swapgs,
+
++#ifdef CONFIG_X86_IOPL_IOPERM
++ .cpu.update_io_bitmap = native_tss_update_io_bitmap,
++#endif
++
+ .cpu.start_context_switch = paravirt_nop,
+ .cpu.end_context_switch = paravirt_nop,
+
+--- a/arch/x86/kernel/process.c
++++ b/arch/x86/kernel/process.c
+@@ -374,7 +374,7 @@ static void tss_copy_io_bitmap(struct ts
+ /**
+ * tss_update_io_bitmap - Update I/O bitmap before exiting to usermode
+ */
+-void tss_update_io_bitmap(void)
++void native_tss_update_io_bitmap(void)
+ {
+ struct tss_struct *tss = this_cpu_ptr(&cpu_tss_rw);
+ struct thread_struct *t = ¤t->thread;
+--- a/arch/x86/xen/enlighten_pv.c
++++ b/arch/x86/xen/enlighten_pv.c
+@@ -72,6 +72,9 @@
+ #include <asm/mwait.h>
+ #include <asm/pci_x86.h>
+ #include <asm/cpu.h>
++#ifdef CONFIG_X86_IOPL_IOPERM
++#include <asm/io_bitmap.h>
++#endif
+
+ #ifdef CONFIG_ACPI
+ #include <linux/acpi.h>
+@@ -837,6 +840,25 @@ static void xen_load_sp0(unsigned long s
+ this_cpu_write(cpu_tss_rw.x86_tss.sp0, sp0);
+ }
+
++#ifdef CONFIG_X86_IOPL_IOPERM
++static void xen_update_io_bitmap(void)
++{
++ struct physdev_set_iobitmap iobitmap;
++ struct tss_struct *tss = this_cpu_ptr(&cpu_tss_rw);
++
++ native_tss_update_io_bitmap();
++
++ iobitmap.bitmap = (uint8_t *)(&tss->x86_tss) +
++ tss->x86_tss.io_bitmap_base;
++ if (tss->x86_tss.io_bitmap_base == IO_BITMAP_OFFSET_INVALID)
++ iobitmap.nr_ports = 0;
++ else
++ iobitmap.nr_ports = IO_BITMAP_BITS;
++
++ HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &iobitmap);
++}
++#endif
++
+ static void xen_io_delay(void)
+ {
+ }
+@@ -1047,6 +1069,9 @@ static const struct pv_cpu_ops xen_cpu_o
+ .write_idt_entry = xen_write_idt_entry,
+ .load_sp0 = xen_load_sp0,
+
++#ifdef CONFIG_X86_IOPL_IOPERM
++ .update_io_bitmap = xen_update_io_bitmap,
++#endif
+ .io_delay = xen_io_delay,
+
+ /* Xen takes care of %gs when switching to usermode for us */
--- /dev/null
+From 735a6dd02222d8d070c7bb748f25895239ca8c92 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 26 Feb 2020 15:16:15 -0800
+Subject: x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 735a6dd02222d8d070c7bb748f25895239ca8c92 upstream.
+
+Explicitly set X86_FEATURE_OSPKE via set_cpu_cap() instead of calling
+get_cpu_cap() to pull the feature bit from CPUID after enabling CR4.PKE.
+Invoking get_cpu_cap() effectively wipes out any {set,clear}_cpu_cap()
+changes that were made between this_cpu->c_init() and setup_pku(), as
+all non-synthetic feature words are reinitialized from the CPU's CPUID
+values.
+
+Blasting away capability updates manifests most visibility when running
+on a VMX capable CPU, but with VMX disabled by BIOS. To indicate that
+VMX is disabled, init_ia32_feat_ctl() clears X86_FEATURE_VMX, using
+clear_cpu_cap() instead of setup_clear_cpu_cap() so that KVM can report
+which CPU is misconfigured (KVM needs to probe every CPU anyways).
+Restoring X86_FEATURE_VMX from CPUID causes KVM to think VMX is enabled,
+ultimately leading to an unexpected #GP when KVM attempts to do VMXON.
+
+Arguably, init_ia32_feat_ctl() should use setup_clear_cpu_cap() and let
+KVM figure out a different way to report the misconfigured CPU, but VMX
+is not the only feature bit that is affected, i.e. there is precedent
+that tweaking feature bits via {set,clear}_cpu_cap() after ->c_init()
+is expected to work. Most notably, x86_init_rdrand()'s clearing of
+X86_FEATURE_RDRAND when RDRAND malfunctions is also overwritten.
+
+Fixes: 0697694564c8 ("x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU")
+Reported-by: Jacob Keller <jacob.e.keller@intel.com>
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Tested-by: Jacob Keller <jacob.e.keller@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200226231615.13664-1-sean.j.christopherson@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/common.c
++++ b/arch/x86/kernel/cpu/common.c
+@@ -462,7 +462,7 @@ static __always_inline void setup_pku(st
+ * cpuid bit to be set. We need to ensure that we
+ * update that bit in this CPU's "cpu_info".
+ */
+- get_cpu_cap(c);
++ set_cpu_cap(c, X86_FEATURE_OSPKE);
+ }
+
+ #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
projects / thirdparty / kernel / stable-queue.git / commitdiff
