From: Greg Kroah-Hartman Date: Mon, 9 Mar 2020 19:36:28 +0000 (+0100) Subject: 5.5-stable patches X-Git-Tag: v4.4.216~43 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2da29f7420868d9212a1443f8a284da288fe0762;p=thirdparty%2Fkernel%2Fstable-queue.git 5.5-stable patches added patches: dmaengine-imx-sdma-fix-context-cache.patch dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch drm-amd-powerplay-fix-pre-check-condition-for-setting-clock-range.patch drm-amdgpu-disable-3d-pipe-1-on-navi1x.patch drm-shmem-add-support-for-per-object-caching-flags.patch drm-virtio-fix-mmap-page-attributes.patch media-hantro-fix-broken-media-controller-links.patch media-mc-entity.c-use-to-check-pad-flags-not.patch media-v4l2-mem2mem.c-fix-broken-links.patch media-vicodec-process-all-4-components-for-rgb32-formats.patch perf-arm-spe-fix-endless-record-after-being-terminated.patch perf-cs-etm-fix-endless-record-after-being-terminated.patch perf-intel-bts-fix-endless-record-after-being-terminated.patch perf-intel-pt-fix-endless-record-after-being-terminated.patch powerpc-mm-fix-missing-kuap-disable-in-flush_coherent_icache.patch s390-mm-fix-panic-in-gup_fast-on-large-pud.patch s390-pci-fix-unexpected-write-combine-on-resource.patch selftests-pidfd-add-pidfd_fdinfo_test-in-.gitignore.patch spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch vt-selection-push-sel_lock-up.patch x86-ioperm-add-new-paravirt-function-update_io_bitmap.patch x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch --- diff --git a/queue-5.5/dmaengine-imx-sdma-fix-context-cache.patch b/queue-5.5/dmaengine-imx-sdma-fix-context-cache.patch new file mode 100644 index 00000000000..61999e201c9 --- /dev/null +++ b/queue-5.5/dmaengine-imx-sdma-fix-context-cache.patch @@ -0,0 +1,65 @@ +From d288bddd8374e0a043ac9dde64a1ae6a09411d74 Mon Sep 17 00:00:00 2001 +From: Martin Fuzzey +Date: Wed, 29 Jan 2020 14:40:06 +0100 +Subject: dmaengine: imx-sdma: fix context cache + +From: Martin Fuzzey + +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 +Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") +Reviewed-by: Fabio Estevam +Link: https://lore.kernel.org/r/1580305274-27274-1-git-send-email-martin.fuzzey@flowbird.group +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-5.5/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch b/queue-5.5/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch new file mode 100644 index 00000000000..5c7cd6bf45e --- /dev/null +++ b/queue-5.5/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch @@ -0,0 +1,45 @@ +From 25962e1a7f1d522f1b57ead2f266fab570042a70 Mon Sep 17 00:00:00 2001 +From: Frieder Schrempf +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 + +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 +Reviewed-by: Fabio Estevam +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200225082139.7646-1-frieder.schrempf@kontron.de +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.5/drm-amd-powerplay-fix-pre-check-condition-for-setting-clock-range.patch b/queue-5.5/drm-amd-powerplay-fix-pre-check-condition-for-setting-clock-range.patch new file mode 100644 index 00000000000..e447eeec50c --- /dev/null +++ b/queue-5.5/drm-amd-powerplay-fix-pre-check-condition-for-setting-clock-range.patch @@ -0,0 +1,52 @@ +From 80381d40c9bf5218db06a7d7246c5478c95987ee Mon Sep 17 00:00:00 2001 +From: Prike Liang +Date: Mon, 2 Mar 2020 09:36:15 +0800 +Subject: drm/amd/powerplay: fix pre-check condition for setting clock range + +From: Prike Liang + +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 +Reviewed-by: Evan Quan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-5.5/drm-amdgpu-disable-3d-pipe-1-on-navi1x.patch b/queue-5.5/drm-amdgpu-disable-3d-pipe-1-on-navi1x.patch new file mode 100644 index 00000000000..bffccf7ac29 --- /dev/null +++ b/queue-5.5/drm-amdgpu-disable-3d-pipe-1-on-navi1x.patch @@ -0,0 +1,162 @@ +From 194bcf35bce4a236059816bc41b3db9c9c92a1bb Mon Sep 17 00:00:00 2001 +From: "Tianci.Yin" +Date: Fri, 28 Feb 2020 17:10:21 +0800 +Subject: drm/amdgpu: disable 3D pipe 1 on Navi1x + +From: Tianci.Yin + +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 +Reviewed-by: Monk Liu +Signed-off-by: Tianci.Yin +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.5/drm-shmem-add-support-for-per-object-caching-flags.patch b/queue-5.5/drm-shmem-add-support-for-per-object-caching-flags.patch new file mode 100644 index 00000000000..422c3fc0e20 --- /dev/null +++ b/queue-5.5/drm-shmem-add-support-for-per-object-caching-flags.patch @@ -0,0 +1,72 @@ +From 1cad629257e76025bcbf490c58de550fb67d4d0e Mon Sep 17 00:00:00 2001 +From: Gerd Hoffmann +Date: Wed, 26 Feb 2020 16:47:50 +0100 +Subject: drm/shmem: add support for per object caching flags. + +From: Gerd Hoffmann + +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 +Reviewed-by: Gurchetan Singh +Tested-by: Guillaume Gardet +Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-2-kraxel@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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) \ diff --git a/queue-5.5/drm-virtio-fix-mmap-page-attributes.patch b/queue-5.5/drm-virtio-fix-mmap-page-attributes.patch new file mode 100644 index 00000000000..f36b495c400 --- /dev/null +++ b/queue-5.5/drm-virtio-fix-mmap-page-attributes.patch @@ -0,0 +1,36 @@ +From 6be7e07335486f5731cab748d80c68f20896581f Mon Sep 17 00:00:00 2001 +From: Gerd Hoffmann +Date: Wed, 26 Feb 2020 16:47:51 +0100 +Subject: drm/virtio: fix mmap page attributes + +From: Gerd Hoffmann + +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 +Reported-by: Guillaume Gardet +Signed-off-by: Gerd Hoffmann +Reviewed-by: Gurchetan Singh +Tested-by: Guillaume Gardet +Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-3-kraxel@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-5.5/media-hantro-fix-broken-media-controller-links.patch b/queue-5.5/media-hantro-fix-broken-media-controller-links.patch new file mode 100644 index 00000000000..71934e6f533 --- /dev/null +++ b/queue-5.5/media-hantro-fix-broken-media-controller-links.patch @@ -0,0 +1,43 @@ +From d171c45da874e3858a83e6377e00280a507fe2f2 Mon Sep 17 00:00:00 2001 +From: Ezequiel Garcia +Date: Tue, 4 Feb 2020 20:38:37 +0100 +Subject: media: hantro: Fix broken media controller links + +From: Ezequiel Garcia + +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 +Cc: # for v5.3 and up +Signed-off-by: Ezequiel Garcia +Tested-by: Nicolas Dufresne +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-5.5/media-mc-entity.c-use-to-check-pad-flags-not.patch b/queue-5.5/media-mc-entity.c-use-to-check-pad-flags-not.patch new file mode 100644 index 00000000000..38b39488b17 --- /dev/null +++ b/queue-5.5/media-mc-entity.c-use-to-check-pad-flags-not.patch @@ -0,0 +1,39 @@ +From 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 19:19:22 +0100 +Subject: media: mc-entity.c: use & to check pad flags, not == + +From: Hans Verkuil + +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 +Cc: # for v5.3 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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! */ diff --git a/queue-5.5/media-v4l2-mem2mem.c-fix-broken-links.patch b/queue-5.5/media-v4l2-mem2mem.c-fix-broken-links.patch new file mode 100644 index 00000000000..d39ac75bb7f --- /dev/null +++ b/queue-5.5/media-v4l2-mem2mem.c-fix-broken-links.patch @@ -0,0 +1,43 @@ +From 316e730f1d8bb029fe6cec2468fb2a50424485b3 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 19:13:06 +0100 +Subject: media: v4l2-mem2mem.c: fix broken links + +From: Hans Verkuil + +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 +Reported-by: Nicolas Dufresne +Cc: # for v4.19 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/media-vicodec-process-all-4-components-for-rgb32-formats.patch b/queue-5.5/media-vicodec-process-all-4-components-for-rgb32-formats.patch new file mode 100644 index 00000000000..329aa8d8134 --- /dev/null +++ b/queue-5.5/media-vicodec-process-all-4-components-for-rgb32-formats.patch @@ -0,0 +1,105 @@ +From 49a56266f96f2c6608373464af8755b431ef1513 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 13:45:04 +0100 +Subject: media: vicodec: process all 4 components for RGB32 formats + +From: Hans Verkuil + +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 +Cc: # for v5.4 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/perf-arm-spe-fix-endless-record-after-being-terminated.patch b/queue-5.5/perf-arm-spe-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..700d75bb8ce --- /dev/null +++ b/queue-5.5/perf-arm-spe-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,47 @@ +From d6bc34c5ec18c3544c4b0d85963768dfbcd24184 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 14 Feb 2020 15:26:53 +0200 +Subject: perf arm-spe: Fix endless record after being terminated + +From: Adrian Hunter + +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 +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: Tan Xiaojun +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-5.5/perf-cs-etm-fix-endless-record-after-being-terminated.patch b/queue-5.5/perf-cs-etm-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..0ad9d76150a --- /dev/null +++ b/queue-5.5/perf-cs-etm-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,60 @@ +From c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:52 +0200 +Subject: perf cs-etm: Fix endless record after being terminated + +From: Wei Li + +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 +Reviewed-by: Leo Yan +Reviewed-by: Mathieu Poirier +Tested-by: Leo Yan +Cc: Jiri Olsa +Cc: Tan Xiaojun +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 +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/perf-intel-bts-fix-endless-record-after-being-terminated.patch b/queue-5.5/perf-intel-bts-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..9d8ea4b4426 --- /dev/null +++ b/queue-5.5/perf-intel-bts-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,52 @@ +From 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:51 +0200 +Subject: perf intel-bts: Fix endless record after being terminated + +From: Wei Li + +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 +Cc: Jiri Olsa +Cc: Tan Xiaojun +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 +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-5.5/perf-intel-pt-fix-endless-record-after-being-terminated.patch b/queue-5.5/perf-intel-pt-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..53b3f445cdc --- /dev/null +++ b/queue-5.5/perf-intel-pt-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,63 @@ +From 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:50 +0200 +Subject: perf intel-pt: Fix endless record after being terminated + +From: Wei Li + +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 +Cc: Jiri Olsa +Cc: Tan Xiaojun +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 +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-5.5/powerpc-mm-fix-missing-kuap-disable-in-flush_coherent_icache.patch b/queue-5.5/powerpc-mm-fix-missing-kuap-disable-in-flush_coherent_icache.patch new file mode 100644 index 00000000000..0e5dbf111fd --- /dev/null +++ b/queue-5.5/powerpc-mm-fix-missing-kuap-disable-in-flush_coherent_icache.patch @@ -0,0 +1,88 @@ +From 59bee45b9712c759ea4d3dcc4eff1752f3a66558 Mon Sep 17 00:00:00 2001 +From: Michael Ellerman +Date: Tue, 3 Mar 2020 23:28:47 +1100 +Subject: powerpc/mm: Fix missing KUAP disable in flush_coherent_icache() + +From: Michael Ellerman + +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 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 +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20200303235708.26004-1-mpe@ellerman.id.au +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch b/queue-5.5/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch new file mode 100644 index 00000000000..ed1db975c73 --- /dev/null +++ b/queue-5.5/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch @@ -0,0 +1,49 @@ +From 582b4e55403e053d8a48ff687a05174da9cc3fb0 Mon Sep 17 00:00:00 2001 +From: Gerald Schaefer +Date: Thu, 27 Feb 2020 12:56:42 +0100 +Subject: s390/mm: fix panic in gup_fast on large pud + +From: Gerald Schaefer + +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: # 5.2+ +Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code") +Signed-off-by: Gerald Schaefer +Reviewed-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/s390-pci-fix-unexpected-write-combine-on-resource.patch b/queue-5.5/s390-pci-fix-unexpected-write-combine-on-resource.patch new file mode 100644 index 00000000000..917acc4508e --- /dev/null +++ b/queue-5.5/s390-pci-fix-unexpected-write-combine-on-resource.patch @@ -0,0 +1,50 @@ +From df057c914a9c219ac8b8ed22caf7da2f80c1fe26 Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Thu, 27 Feb 2020 12:17:18 +0100 +Subject: s390/pci: Fix unexpected write combine on resource + +From: Niklas Schnelle + +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 +Reviewed-by: Pierre Morel +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-5.5/selftests-pidfd-add-pidfd_fdinfo_test-in-.gitignore.patch b/queue-5.5/selftests-pidfd-add-pidfd_fdinfo_test-in-.gitignore.patch new file mode 100644 index 00000000000..43903b1e16f --- /dev/null +++ b/queue-5.5/selftests-pidfd-add-pidfd_fdinfo_test-in-.gitignore.patch @@ -0,0 +1,31 @@ +From 186e28a18aeb0fec99cc586fda337e6b23190791 Mon Sep 17 00:00:00 2001 +From: Christophe Leroy +Date: Fri, 28 Feb 2020 00:00:08 +0000 +Subject: selftests: pidfd: Add pidfd_fdinfo_test in .gitignore + +From: Christophe Leroy + +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 +Acked-by: Christian Brauner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/966567c7dbaa26a06730d796354f8a086c0ee288.1582847778.git.christophe.leroy@c-s.fr +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-5.5/series b/queue-5.5/series index da9e4ba47f8..6fac66b313b 100644 --- a/queue-5.5/series +++ b/queue-5.5/series @@ -93,3 +93,25 @@ serial-8250_exar-add-support-for-acces-cards.patch 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 diff --git a/queue-5.5/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch b/queue-5.5/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch new file mode 100644 index 00000000000..c2e3e922483 --- /dev/null +++ b/queue-5.5/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch @@ -0,0 +1,55 @@ +From 138c9c32f090894614899eca15e0bb7279f59865 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Tue, 18 Feb 2020 13:08:00 +0100 +Subject: spi: spidev: Fix CS polarity if GPIO descriptors are used + +From: Lukas Wunner + +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 +Signed-off-by: Lukas Wunner +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas@wunner.de +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org # v5.1+ +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.5/vt-selection-push-sel_lock-up.patch b/queue-5.5/vt-selection-push-sel_lock-up.patch new file mode 100644 index 00000000000..9810799fc0a --- /dev/null +++ b/queue-5.5/vt-selection-push-sel_lock-up.patch @@ -0,0 +1,145 @@ +From e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Fri, 28 Feb 2020 12:54:06 +0100 +Subject: vt: selection, push sel_lock up + +From: Jiri Slaby + +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 +Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com +Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race") +Cc: stable +Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-5.5/x86-ioperm-add-new-paravirt-function-update_io_bitmap.patch b/queue-5.5/x86-ioperm-add-new-paravirt-function-update_io_bitmap.patch new file mode 100644 index 00000000000..61666351826 --- /dev/null +++ b/queue-5.5/x86-ioperm-add-new-paravirt-function-update_io_bitmap.patch @@ -0,0 +1,164 @@ +From 99bcd4a6e5b8ba201fdd252f1054689884899fee Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Tue, 18 Feb 2020 16:47:12 +0100 +Subject: x86/ioperm: Add new paravirt function update_io_bitmap() + +From: Juergen Gross + +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 +Signed-off-by: Juergen Gross +Signed-off-by: Thomas Gleixner +Tested-by: Jan Beulich +Reviewed-by: Jan Beulich +Cc: # 5.5 +Link: https://lkml.kernel.org/r/20200218154712.25490-1-jgross@suse.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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 ++#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 + #include + #include ++#include + + /* + * 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 + #include + #include ++#ifdef CONFIG_X86_IOPL_IOPERM ++#include ++#endif + + #ifdef CONFIG_ACPI + #include +@@ -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 */ diff --git a/queue-5.5/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch b/queue-5.5/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch new file mode 100644 index 00000000000..13841f6531e --- /dev/null +++ b/queue-5.5/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch @@ -0,0 +1,56 @@ +From 735a6dd02222d8d070c7bb748f25895239ca8c92 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 26 Feb 2020 15:16:15 -0800 +Subject: x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes + +From: Sean Christopherson + +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 +Signed-off-by: Sean Christopherson +Signed-off-by: Borislav Petkov +Acked-by: Dave Hansen +Tested-by: Jacob Keller +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 + +--- + 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