From 30f56761c1f76c413ee9af8ce857c11ea3564324 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 16 Oct 2022 12:53:44 +0200 Subject: [PATCH] 5.15-stable patches added patches: arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch dmaengine-mxs-use-platform_driver_register.patch drm-udl-restore-display-mode-on-resume.patch drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch nvmem-core-fix-memleak-in-nvmem_register.patch revert-drm-amdgpu-use-dirty-framebuffer-helper.patch um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch --- ...d-cortex-a55-to-the-repeat-tlbi-list.patch | 79 +++++++++++++++++++ ...ine-mxs-use-platform_driver_register.patch | 70 ++++++++++++++++ ...m-udl-restore-display-mode-on-resume.patch | 50 ++++++++++++ ...k-whether-transferred-2d-bo-is-shmem.patch | 33 ++++++++ ...n-virtio_gpu_object_shmem_init-error.patch | 35 ++++++++ ...state-in-virtio_gpu_plane_cleanup_fb.patch | 43 ++++++++++ ...ng-in-live-ns-resize-with-ana-access.patch | 66 ++++++++++++++++ ...sk-before-calculating-max_hw_sectors.patch | 40 ++++++++++ ...m-core-fix-memleak-in-nvmem_register.patch | 57 +++++++++++++ ...-amdgpu-use-dirty-framebuffer-helper.patch | 64 +++++++++++++++ queue-5.15/series | 11 +++ ...-warning-for-config_cpumask_offstack.patch | 62 +++++++++++++++ 12 files changed, 610 insertions(+) create mode 100644 queue-5.15/arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch create mode 100644 queue-5.15/dmaengine-mxs-use-platform_driver_register.patch create mode 100644 queue-5.15/drm-udl-restore-display-mode-on-resume.patch create mode 100644 queue-5.15/drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch create mode 100644 queue-5.15/drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch create mode 100644 queue-5.15/drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch create mode 100644 queue-5.15/nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch create mode 100644 queue-5.15/nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch create mode 100644 queue-5.15/nvmem-core-fix-memleak-in-nvmem_register.patch create mode 100644 queue-5.15/revert-drm-amdgpu-use-dirty-framebuffer-helper.patch create mode 100644 queue-5.15/um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch diff --git a/queue-5.15/arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch b/queue-5.15/arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch new file mode 100644 index 00000000000..7d2ed9620bf --- /dev/null +++ b/queue-5.15/arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch @@ -0,0 +1,79 @@ +From 171df58028bf4649460fb146a56a58dcb0c8f75a Mon Sep 17 00:00:00 2001 +From: James Morse +Date: Fri, 30 Sep 2022 14:19:59 +0100 +Subject: arm64: errata: Add Cortex-A55 to the repeat tlbi list + +From: James Morse + +commit 171df58028bf4649460fb146a56a58dcb0c8f75a upstream. + +Cortex-A55 is affected by an erratum where in rare circumstances the +CPUs may not handle a race between a break-before-make sequence on one +CPU, and another CPU accessing the same page. This could allow a store +to a page that has been unmapped. + +Work around this by adding the affected CPUs to the list that needs +TLB sequences to be done twice. + +Signed-off-by: James Morse +Cc: +Link: https://lore.kernel.org/r/20220930131959.3082594-1-james.morse@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/arm64/silicon-errata.rst | 2 ++ + arch/arm64/Kconfig | 17 +++++++++++++++++ + arch/arm64/kernel/cpu_errata.c | 5 +++++ + 3 files changed, 24 insertions(+) + +--- a/Documentation/arm64/silicon-errata.rst ++++ b/Documentation/arm64/silicon-errata.rst +@@ -68,6 +68,8 @@ stable kernels. + +----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 | + +----------------+-----------------+-----------------+-----------------------------+ ++| ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 | +++----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | + +----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A57 | #852523 | N/A | +--- a/arch/arm64/Kconfig ++++ b/arch/arm64/Kconfig +@@ -596,6 +596,23 @@ config ARM64_ERRATUM_1530923 + config ARM64_WORKAROUND_REPEAT_TLBI + bool + ++config ARM64_ERRATUM_2441007 ++ bool "Cortex-A55: Completion of affected memory accesses might not be guaranteed by completion of a TLBI" ++ default y ++ select ARM64_WORKAROUND_REPEAT_TLBI ++ help ++ This option adds a workaround for ARM Cortex-A55 erratum #2441007. ++ ++ Under very rare circumstances, affected Cortex-A55 CPUs ++ may not handle a race between a break-before-make sequence on one ++ CPU, and another CPU accessing the same page. This could allow a ++ store to a page that has been unmapped. ++ ++ Work around this by adding the affected CPUs to the list that needs ++ TLB sequences to be done twice. ++ ++ If unsure, say Y. ++ + config ARM64_ERRATUM_1286807 + bool "Cortex-A76: Modification of the translation table for a virtual address might lead to read-after-read ordering violation" + default y +--- a/arch/arm64/kernel/cpu_errata.c ++++ b/arch/arm64/kernel/cpu_errata.c +@@ -214,6 +214,11 @@ static const struct arm64_cpu_capabiliti + ERRATA_MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xe), + }, + #endif ++#ifdef CONFIG_ARM64_ERRATUM_2441007 ++ { ++ ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A55), ++ }, ++#endif + #ifdef CONFIG_ARM64_ERRATUM_2441009 + { + /* Cortex-A510 r0p0 -> r1p1. Fixed in r1p2 */ diff --git a/queue-5.15/dmaengine-mxs-use-platform_driver_register.patch b/queue-5.15/dmaengine-mxs-use-platform_driver_register.patch new file mode 100644 index 00000000000..4d1486c7a7b --- /dev/null +++ b/queue-5.15/dmaengine-mxs-use-platform_driver_register.patch @@ -0,0 +1,70 @@ +From 26696d4657167112a1079f86cba1739765c1360e Mon Sep 17 00:00:00 2001 +From: Dario Binacchi +Date: Wed, 21 Sep 2022 19:05:56 +0200 +Subject: dmaengine: mxs: use platform_driver_register + +From: Dario Binacchi + +commit 26696d4657167112a1079f86cba1739765c1360e upstream. + +Driver registration fails on SOC imx8mn as its supplier, the clock +control module, is probed later than subsys initcall level. This driver +uses platform_driver_probe which is not compatible with deferred probing +and won't be probed again later if probe function fails due to clock not +being available at that time. + +This patch replaces the use of platform_driver_probe with +platform_driver_register which will allow probing the driver later again +when the clock control module will be available. + +The __init annotation has been dropped because it is not compatible with +deferred probing. The code is not executed once and its memory cannot be +freed. + +Fixes: a580b8c5429a ("dmaengine: mxs-dma: add dma support for i.MX23/28") +Co-developed-by: Michael Trimarchi +Signed-off-by: Michael Trimarchi +Signed-off-by: Dario Binacchi +Acked-by: Sascha Hauer +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +Link: https://lore.kernel.org/r/20220921170556.1055962-1-dario.binacchi@amarulasolutions.com +Signed-off-by: Vinod Koul +--- + drivers/dma/mxs-dma.c | 11 ++++------- + 1 file changed, 4 insertions(+), 7 deletions(-) + +--- a/drivers/dma/mxs-dma.c ++++ b/drivers/dma/mxs-dma.c +@@ -670,7 +670,7 @@ static enum dma_status mxs_dma_tx_status + return mxs_chan->status; + } + +-static int __init mxs_dma_init(struct mxs_dma_engine *mxs_dma) ++static int mxs_dma_init(struct mxs_dma_engine *mxs_dma) + { + int ret; + +@@ -741,7 +741,7 @@ static struct dma_chan *mxs_dma_xlate(st + ofdma->of_node); + } + +-static int __init mxs_dma_probe(struct platform_device *pdev) ++static int mxs_dma_probe(struct platform_device *pdev) + { + struct device_node *np = pdev->dev.of_node; + const struct mxs_dma_type *dma_type; +@@ -839,10 +839,7 @@ static struct platform_driver mxs_dma_dr + .name = "mxs-dma", + .of_match_table = mxs_dma_dt_ids, + }, ++ .probe = mxs_dma_probe, + }; + +-static int __init mxs_dma_module_init(void) +-{ +- return platform_driver_probe(&mxs_dma_driver, mxs_dma_probe); +-} +-subsys_initcall(mxs_dma_module_init); ++builtin_platform_driver(mxs_dma_driver); diff --git a/queue-5.15/drm-udl-restore-display-mode-on-resume.patch b/queue-5.15/drm-udl-restore-display-mode-on-resume.patch new file mode 100644 index 00000000000..05d58c75b6e --- /dev/null +++ b/queue-5.15/drm-udl-restore-display-mode-on-resume.patch @@ -0,0 +1,50 @@ +From 6d6e732835db92e66c28dbcf258a7e3d3c71420d Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 8 Sep 2022 11:51:04 +0200 +Subject: drm/udl: Restore display mode on resume + +From: Takashi Iwai + +commit 6d6e732835db92e66c28dbcf258a7e3d3c71420d upstream. + +Restore the display mode whne resuming from suspend. Currently, the +display remains dark. + +On resume, the CRTC's mode does not change, but the 'active' flag +changes to 'true'. Taking this into account when considering a mode +switch restores the display mode. + +The bug is reproducable by using Gnome with udl and observing the +adapter's suspend/resume behavior. + +Actually, the whole check added in udl_simple_display_pipe_enable() +about the crtc_state->mode_changed was bogus. We should drop the +whole check and always apply the mode change in this function. + +[ tiwai -- Drop the mode_changed check entirely instead, per Daniel's + suggestion ] + +Fixes: 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable functions") +Cc: +Suggested-by: Daniel Vetter +Reviewed-by: Daniel Vetter +Signed-off-by: Takashi Iwai +Signed-off-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-2-tiwai@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/udl/udl_modeset.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/gpu/drm/udl/udl_modeset.c ++++ b/drivers/gpu/drm/udl/udl_modeset.c +@@ -381,9 +381,6 @@ udl_simple_display_pipe_enable(struct dr + + udl_handle_damage(fb, &shadow_plane_state->data[0], 0, 0, fb->width, fb->height); + +- if (!crtc_state->mode_changed) +- return; +- + /* enable display */ + udl_crtc_write_mode_to_hw(crtc); + } diff --git a/queue-5.15/drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch b/queue-5.15/drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch new file mode 100644 index 00000000000..c0c02be548f --- /dev/null +++ b/queue-5.15/drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch @@ -0,0 +1,33 @@ +From e473216b42aa1fd9fc6b94b608b42c210c655908 Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Thu, 30 Jun 2022 23:07:19 +0300 +Subject: drm/virtio: Check whether transferred 2D BO is shmem + +From: Dmitry Osipenko + +commit e473216b42aa1fd9fc6b94b608b42c210c655908 upstream. + +Transferred 2D BO always must be a shmem BO. Add check for that to prevent +NULL dereference if userspace passes a VRAM BO. + +Cc: stable@vger.kernel.org +Reviewed-by: Emil Velikov +Signed-off-by: Dmitry Osipenko +Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-3-dmitry.osipenko@collabora.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/virtio/virtgpu_vq.c ++++ b/drivers/gpu/drm/virtio/virtgpu_vq.c +@@ -604,7 +604,7 @@ void virtio_gpu_cmd_transfer_to_host_2d( + bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); + struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); + +- if (use_dma_api) ++ if (virtio_gpu_is_shmem(bo) && use_dma_api) + dma_sync_sgtable_for_device(vgdev->vdev->dev.parent, + shmem->pages, DMA_TO_DEVICE); + diff --git a/queue-5.15/drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch b/queue-5.15/drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch new file mode 100644 index 00000000000..25abc944aad --- /dev/null +++ b/queue-5.15/drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch @@ -0,0 +1,35 @@ +From fdf0ff4d12cbcd76b53f27c96ce51ddca400884a Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Thu, 30 Jun 2022 23:07:20 +0300 +Subject: drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error + +From: Dmitry Osipenko + +commit fdf0ff4d12cbcd76b53f27c96ce51ddca400884a upstream. + +Unlock reservations in the error code path of virtio_gpu_object_create() +to silence debug warning splat produced by ww_mutex_destroy(&obj->lock) +when GEM is released with the held lock. + +Cc: stable@vger.kernel.org +Fixes: 30172efbfb84 ("drm/virtio: blob prep: refactor getting pages and attaching backing") +Reviewed-by: Emil Velikov +Signed-off-by: Dmitry Osipenko +Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-4-dmitry.osipenko@collabora.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/virtio/virtgpu_object.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/virtio/virtgpu_object.c ++++ b/drivers/gpu/drm/virtio/virtgpu_object.c +@@ -247,6 +247,8 @@ int virtio_gpu_object_create(struct virt + + ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents); + if (ret != 0) { ++ if (fence) ++ virtio_gpu_array_unlock_resv(objs); + virtio_gpu_array_put_free(objs); + virtio_gpu_free_object(&shmem_obj->base); + return ret; diff --git a/queue-5.15/drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch b/queue-5.15/drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch new file mode 100644 index 00000000000..73b897720ed --- /dev/null +++ b/queue-5.15/drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch @@ -0,0 +1,43 @@ +From 4656b3a26a9e9fe5f04bfd2ab55b066266ba7f4d Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Thu, 30 Jun 2022 23:07:22 +0300 +Subject: drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb() + +From: Dmitry Osipenko + +commit 4656b3a26a9e9fe5f04bfd2ab55b066266ba7f4d upstream. + +Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core +wants to clean up and not the current plane's state. Normally the older +atomic state is cleaned up, but the newer state could also be cleaned up +in case of aborted commits. + +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Osipenko +Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-6-dmitry.osipenko@collabora.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/virtio/virtgpu_plane.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -265,14 +265,14 @@ static int virtio_gpu_plane_prepare_fb(s + } + + static void virtio_gpu_plane_cleanup_fb(struct drm_plane *plane, +- struct drm_plane_state *old_state) ++ struct drm_plane_state *state) + { + struct virtio_gpu_framebuffer *vgfb; + +- if (!plane->state->fb) ++ if (!state->fb) + return; + +- vgfb = to_virtio_gpu_framebuffer(plane->state->fb); ++ vgfb = to_virtio_gpu_framebuffer(state->fb); + if (vgfb->fence) { + dma_fence_put(&vgfb->fence->f); + vgfb->fence = NULL; diff --git a/queue-5.15/nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch b/queue-5.15/nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch new file mode 100644 index 00000000000..0c3f8019e5d --- /dev/null +++ b/queue-5.15/nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch @@ -0,0 +1,66 @@ +From 72e3b8883a36e80ebfa41015c7b6926ce31ace05 Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Thu, 29 Sep 2022 10:36:47 +0300 +Subject: nvme-multipath: fix possible hang in live ns resize with ANA access + +From: Sagi Grimberg + +commit 72e3b8883a36e80ebfa41015c7b6926ce31ace05 upstream. + +When we revalidate paths as part of ns size change (as of commit +e7d65803e2bb), it is possible that during the path revalidation, the +only paths that is IO capable (i.e. optimized/non-optimized) are the +ones that ns resize was not yet informed to the host, which will cause +inflight requests to be requeued (as we have available paths but none +are IO capable). These requests on the requeue list are waiting for +someone to resubmit them at some point. + +The IO capable paths will eventually notify the ns resize change to the +host, but there is nothing that will kick the requeue list to resubmit +the queued requests. + +Fix this by always kicking the requeue list, and if no IO capable path +exists, these requests will be queued again. + +A typical log that indicates that IOs are requeued: +-- +nvme nvme1: creating 4 I/O queues. +nvme nvme1: new ctrl: "testnqn1" +nvme nvme2: creating 4 I/O queues. +nvme nvme2: mapped 4/0/0 default/read/poll queues. +nvme nvme2: new ctrl: NQN "testnqn1", addr 127.0.0.1:8009 +nvme nvme1: rescanning namespaces. +nvme1n1: detected capacity change from 2097152 to 4194304 +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +block nvme1n1: no usable path - requeuing I/O +nvme nvme2: rescanning namespaces. +-- + +Reported-by: Yogev Cohen +Fixes: e7d65803e2bb ("nvme-multipath: revalidate paths during rescan") +Signed-off-by: Sagi Grimberg +Cc: # v5.15+ +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/multipath.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/nvme/host/multipath.c ++++ b/drivers/nvme/host/multipath.c +@@ -159,6 +159,7 @@ void nvme_mpath_revalidate_paths(struct + + for_each_node(node) + rcu_assign_pointer(head->current_path[node], NULL); ++ kblockd_schedule_work(&head->requeue_work); + } + + static bool nvme_path_is_disabled(struct nvme_ns *ns) diff --git a/queue-5.15/nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch b/queue-5.15/nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch new file mode 100644 index 00000000000..e5c2f1c3f4c --- /dev/null +++ b/queue-5.15/nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch @@ -0,0 +1,40 @@ +From 61ce339f19fabbc3e51237148a7ef6f2270e44fa Mon Sep 17 00:00:00 2001 +From: Rishabh Bhatnagar +Date: Tue, 20 Sep 2022 19:19:32 +0000 +Subject: nvme-pci: set min_align_mask before calculating max_hw_sectors + +From: Rishabh Bhatnagar + +commit 61ce339f19fabbc3e51237148a7ef6f2270e44fa upstream. + +If swiotlb is force enabled dma_max_mapping_size ends up calling +swiotlb_max_mapping_size which takes into account the min align mask for +the device. Set the min align mask for nvme driver before calling +dma_max_mapping_size while calculating max hw sectors. + +Signed-off-by: Rishabh Bhatnagar +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/pci.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/nvme/host/pci.c ++++ b/drivers/nvme/host/pci.c +@@ -2732,6 +2732,8 @@ static void nvme_reset_work(struct work_ + if (result) + goto out_unlock; + ++ dma_set_min_align_mask(dev->dev, NVME_CTRL_PAGE_SIZE - 1); ++ + /* + * Limit the max command size to prevent iod->sg allocations going + * over a single page. +@@ -2744,7 +2746,6 @@ static void nvme_reset_work(struct work_ + * Don't limit the IOMMU merged segment size. + */ + dma_set_max_seg_size(dev->dev, 0xffffffff); +- dma_set_min_align_mask(dev->dev, NVME_CTRL_PAGE_SIZE - 1); + + mutex_unlock(&dev->shutdown_lock); + diff --git a/queue-5.15/nvmem-core-fix-memleak-in-nvmem_register.patch b/queue-5.15/nvmem-core-fix-memleak-in-nvmem_register.patch new file mode 100644 index 00000000000..52f2b672876 --- /dev/null +++ b/queue-5.15/nvmem-core-fix-memleak-in-nvmem_register.patch @@ -0,0 +1,57 @@ +From bd1244561fa2a4531ded40dbf09c9599084f8b29 Mon Sep 17 00:00:00 2001 +From: Gaosheng Cui +Date: Fri, 16 Sep 2022 13:04:02 +0100 +Subject: nvmem: core: Fix memleak in nvmem_register() + +From: Gaosheng Cui + +commit bd1244561fa2a4531ded40dbf09c9599084f8b29 upstream. + +dev_set_name will alloc memory for nvmem->dev.kobj.name in +nvmem_register, when nvmem_validate_keepouts failed, nvmem's +memory will be freed and return, but nobody will free memory +for nvmem->dev.kobj.name, there will be memleak, so moving +nvmem_validate_keepouts() after device_register() and let +the device core deal with cleaning name in error cases. + +Fixes: de0534df9347 ("nvmem: core: fix error handling while validating keepout regions") +Cc: stable@vger.kernel.org +Signed-off-by: Gaosheng Cui +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20220916120402.38753-1-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvmem/core.c | 15 ++++++--------- + 1 file changed, 6 insertions(+), 9 deletions(-) + +--- a/drivers/nvmem/core.c ++++ b/drivers/nvmem/core.c +@@ -824,21 +824,18 @@ struct nvmem_device *nvmem_register(cons + nvmem->dev.groups = nvmem_dev_groups; + #endif + +- if (nvmem->nkeepout) { +- rval = nvmem_validate_keepouts(nvmem); +- if (rval) { +- ida_free(&nvmem_ida, nvmem->id); +- kfree(nvmem); +- return ERR_PTR(rval); +- } +- } +- + dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name); + + rval = device_register(&nvmem->dev); + if (rval) + goto err_put_device; + ++ if (nvmem->nkeepout) { ++ rval = nvmem_validate_keepouts(nvmem); ++ if (rval) ++ goto err_device_del; ++ } ++ + if (config->compat) { + rval = nvmem_sysfs_setup_compat(nvmem, config); + if (rval) diff --git a/queue-5.15/revert-drm-amdgpu-use-dirty-framebuffer-helper.patch b/queue-5.15/revert-drm-amdgpu-use-dirty-framebuffer-helper.patch new file mode 100644 index 00000000000..dbc1865de4b --- /dev/null +++ b/queue-5.15/revert-drm-amdgpu-use-dirty-framebuffer-helper.patch @@ -0,0 +1,64 @@ +From 17d819e2828cacca2e4c909044eb9798ed379cd2 Mon Sep 17 00:00:00 2001 +From: Hamza Mahfooz +Date: Wed, 5 Oct 2022 11:30:38 -0400 +Subject: Revert "drm/amdgpu: use dirty framebuffer helper" + +From: Hamza Mahfooz + +commit 17d819e2828cacca2e4c909044eb9798ed379cd2 upstream. + +This reverts commit 66f99628eb24409cb8feb5061f78283c8b65f820. + +Unfortunately, that commit causes performance regressions on non-PSR +setups. So, just revert it until FB_DAMAGE_CLIPS support can be added. + +Cc: stable@vger.kernel.org +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2189 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=216554 +Fixes: 66f99628eb2440 ("drm/amdgpu: use dirty framebuffer helper") +Fixes: abbc7a3dafb91b ("drm/amdgpu: don't register a dirty callback for non-atomic") +Signed-off-by: Hamza Mahfooz +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14 ++------------ + 1 file changed, 2 insertions(+), 12 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +@@ -35,8 +35,6 @@ + #include + #include + #include +-#include +-#include + #include + #include + #include +@@ -494,12 +492,6 @@ static const struct drm_framebuffer_func + .create_handle = drm_gem_fb_create_handle, + }; + +-static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = { +- .destroy = drm_gem_fb_destroy, +- .create_handle = drm_gem_fb_create_handle, +- .dirty = drm_atomic_helper_dirtyfb, +-}; +- + uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev, + uint64_t bo_flags) + { +@@ -1117,10 +1109,8 @@ int amdgpu_display_gem_fb_verify_and_ini + if (ret) + goto err; + +- if (drm_drv_uses_atomic_modeset(dev)) +- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs_atomic); +- else +- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs); ++ ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs); ++ + if (ret) + goto err; + diff --git a/queue-5.15/series b/queue-5.15/series index db58c7930f9..87d54768ce5 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -43,3 +43,14 @@ riscv-allow-prot_write-only-mmap.patch riscv-make-vm_write-imply-vm_read.patch riscv-always-honor-the-config_cmdline_force-when-parsing-dtb.patch riscv-pass-mno-relax-only-on-lld-15.0.0.patch +um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch +nvmem-core-fix-memleak-in-nvmem_register.patch +nvme-multipath-fix-possible-hang-in-live-ns-resize-with-ana-access.patch +nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch +revert-drm-amdgpu-use-dirty-framebuffer-helper.patch +dmaengine-mxs-use-platform_driver_register.patch +drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch +drm-virtio-unlock-reservations-on-virtio_gpu_object_shmem_init-error.patch +drm-virtio-use-appropriate-atomic-state-in-virtio_gpu_plane_cleanup_fb.patch +drm-udl-restore-display-mode-on-resume.patch +arm64-errata-add-cortex-a55-to-the-repeat-tlbi-list.patch diff --git a/queue-5.15/um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch b/queue-5.15/um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch new file mode 100644 index 00000000000..5803a85fcc2 --- /dev/null +++ b/queue-5.15/um-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch @@ -0,0 +1,62 @@ +From 16c546e148fa6d14a019431436a6f7b4087dbccd Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Tue, 12 Jul 2022 15:52:55 +0800 +Subject: UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK + +From: Huacai Chen + +commit 16c546e148fa6d14a019431436a6f7b4087dbccd upstream. + +When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, +cpu_max_bits_warn() generates a runtime warning similar as below while +we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) +instead of NR_CPUS to iterate CPUs. + +[ 3.052463] ------------[ cut here ]------------ +[ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 +[ 3.070072] Modules linked in: efivarfs autofs4 +[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 +[ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 +[ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 +[ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff +[ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 +[ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa +[ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 +[ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 +[ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 +[ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 +[ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c +[ 3.195868] ... +[ 3.199917] Call Trace: +[ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c +[ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 +[ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 +[ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc +[ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 +[ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 +[ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 +[ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 +[ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 +[ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 +[ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 +[ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- + +Cc: stable@vger.kernel.org +Signed-off-by: Huacai Chen +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + arch/um/kernel/um_arch.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/um/kernel/um_arch.c ++++ b/arch/um/kernel/um_arch.c +@@ -94,7 +94,7 @@ static int show_cpuinfo(struct seq_file + + static void *c_start(struct seq_file *m, loff_t *pos) + { +- return *pos < NR_CPUS ? cpu_data + *pos : NULL; ++ return *pos < nr_cpu_ids ? cpu_data + *pos : NULL; + } + + static void *c_next(struct seq_file *m, void *v, loff_t *pos) -- 2.47.3