From: Greg Kroah-Hartman Date: Tue, 1 Oct 2024 08:20:55 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v6.6.54~115 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=908bb3839f49a376685e2d09299af34edb80eb6f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: drm-vmwgfx-prevent-unmapping-active-read-buffers.patch revert-net-libwx-fix-alloc-msix-vectors-failed.patch xen-allow-mapping-acpi-data-using-a-different-physical-address.patch xen-move-checks-for-e820-conflicts-further-up.patch --- diff --git a/queue-6.6/drm-vmwgfx-prevent-unmapping-active-read-buffers.patch b/queue-6.6/drm-vmwgfx-prevent-unmapping-active-read-buffers.patch new file mode 100644 index 00000000000..9eed160d3f2 --- /dev/null +++ b/queue-6.6/drm-vmwgfx-prevent-unmapping-active-read-buffers.patch @@ -0,0 +1,97 @@ +From aba07b9a0587f50e5d3346eaa19019cf3f86c0ea Mon Sep 17 00:00:00 2001 +From: Zack Rusin +Date: Fri, 16 Aug 2024 14:32:05 -0400 +Subject: drm/vmwgfx: Prevent unmapping active read buffers + +From: Zack Rusin + +commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream. + +The kms paths keep a persistent map active to read and compare the cursor +buffer. These maps can race with each other in simple scenario where: +a) buffer "a" mapped for update +b) buffer "a" mapped for compare +c) do the compare +d) unmap "a" for compare +e) update the cursor +f) unmap "a" for update +At step "e" the buffer has been unmapped and the read contents is bogus. + +Prevent unmapping of active read buffers by simply keeping a count of +how many paths have currently active maps and unmap only when the count +reaches 0. + +Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4") +Cc: Broadcom internal kernel review list +Cc: dri-devel@lists.freedesktop.org +Cc: # v5.19+ +Signed-off-by: Zack Rusin +Link: https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-2-zack.rusin@broadcom.com +Reviewed-by: Martin Krastev +Reviewed-by: Maaz Mombasawala +[Shivani: Modified to apply on v6.6.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 13 +++++++++++-- + drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 3 +++ + 2 files changed, 14 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +@@ -331,6 +331,8 @@ void *vmw_bo_map_and_cache(struct vmw_bo + void *virtual; + int ret; + ++ atomic_inc(&vbo->map_count); ++ + virtual = ttm_kmap_obj_virtual(&vbo->map, ¬_used); + if (virtual) + return virtual; +@@ -353,11 +355,17 @@ void *vmw_bo_map_and_cache(struct vmw_bo + */ + void vmw_bo_unmap(struct vmw_bo *vbo) + { ++ int map_count; ++ + if (vbo->map.bo == NULL) + return; + +- ttm_bo_kunmap(&vbo->map); +- vbo->map.bo = NULL; ++ map_count = atomic_dec_return(&vbo->map_count); ++ ++ if (!map_count) { ++ ttm_bo_kunmap(&vbo->map); ++ vbo->map.bo = NULL; ++ } + } + + +@@ -390,6 +398,7 @@ static int vmw_bo_init(struct vmw_privat + BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3); + vmw_bo->tbo.priority = 3; + vmw_bo->res_tree = RB_ROOT; ++ atomic_set(&vmw_bo->map_count, 0); + + params->size = ALIGN(params->size, PAGE_SIZE); + drm_gem_private_object_init(vdev, &vmw_bo->tbo.base, params->size); +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h +@@ -68,6 +68,8 @@ struct vmw_bo_params { + * @map: Kmap object for semi-persistent mappings + * @res_tree: RB tree of resources using this buffer object as a backing MOB + * @res_prios: Eviction priority counts for attached resources ++ * @map_count: The number of currently active maps. Will differ from the ++ * cpu_writers because it includes kernel maps. + * @cpu_writers: Number of synccpu write grabs. Protected by reservation when + * increased. May be decreased without reservation. + * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB +@@ -86,6 +88,7 @@ struct vmw_bo { + struct rb_root res_tree; + u32 res_prios[TTM_MAX_BO_PRIORITY]; + ++ atomic_t map_count; + atomic_t cpu_writers; + /* Not ref-counted. Protected by binding_mutex */ + struct vmw_resource *dx_query_ctx; diff --git a/queue-6.6/revert-net-libwx-fix-alloc-msix-vectors-failed.patch b/queue-6.6/revert-net-libwx-fix-alloc-msix-vectors-failed.patch new file mode 100644 index 00000000000..f7c9547bea3 --- /dev/null +++ b/queue-6.6/revert-net-libwx-fix-alloc-msix-vectors-failed.patch @@ -0,0 +1,37 @@ +From duanqiangwen@net-swift.com Tue Oct 1 10:14:13 2024 +From: Duanqiang Wen +Date: Mon, 30 Sep 2024 15:33:27 +0800 +Subject: [PATCH net] Revert "net: libwx: fix alloc msix vectors failed" +To: stable@vger.kernel.org, patches@lists.linux.dev, gregkh@linuxfoundation.org, davem@davemloft.net, ashal@kernel.org +Cc: Duanqiang Wen +Message-ID: <20240930073327.130343-1-duanqiangwen@net-swift.com> + +From: Duanqiang Wen + +This reverts commit 69197dfc64007b5292cc960581548f41ccd44828. +commit 937d46ecc5f9 ("net: wangxun: add ethtool_ops for +channel number") changed NIC misc irq from most significant +bit to least significant bit, the former condition is not +required to apply this patch, because we only need to set +irq affinity for NIC queue irq vectors. +this patch is required after commit 937d46ecc5f9 ("net: wangxun: +add ethtool_ops for channel number") was applied, so this is only +relevant to 6.6.y branch. + +Signed-off-by: Duanqiang Wen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/wangxun/libwx/wx_lib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/wangxun/libwx/wx_lib.c ++++ b/drivers/net/ethernet/wangxun/libwx/wx_lib.c +@@ -1585,7 +1585,7 @@ static void wx_set_num_queues(struct wx + */ + static int wx_acquire_msix_vectors(struct wx *wx) + { +- struct irq_affinity affd = { .pre_vectors = 1 }; ++ struct irq_affinity affd = {0, }; + int nvecs, i; + + nvecs = min_t(int, num_online_cpus(), wx->mac.max_msix_vectors); diff --git a/queue-6.6/series b/queue-6.6/series index 4fb0d5c5fbc..bbf26e02bc5 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -391,3 +391,7 @@ io_uring-sqpoll-do-not-allow-pinning-outside-of-cpuset.patch io_uring-check-for-presence-of-task_work-rather-than-tif_notify_signal.patch mm-call-the-security_mmap_file-lsm-hook-in-remap_file_pages.patch drm-amd-display-fix-synaptics-cascaded-panamera-dsc-determination.patch +drm-vmwgfx-prevent-unmapping-active-read-buffers.patch +revert-net-libwx-fix-alloc-msix-vectors-failed.patch +xen-move-checks-for-e820-conflicts-further-up.patch +xen-allow-mapping-acpi-data-using-a-different-physical-address.patch diff --git a/queue-6.6/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch b/queue-6.6/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch new file mode 100644 index 00000000000..ccac8b3adaa --- /dev/null +++ b/queue-6.6/xen-allow-mapping-acpi-data-using-a-different-physical-address.patch @@ -0,0 +1,192 @@ +From 9221222c717dbddac1e3c49906525475d87a3a44 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 9 Aug 2024 17:52:55 +0200 +Subject: xen: allow mapping ACPI data using a different physical address + +From: Juergen Gross + +commit 9221222c717dbddac1e3c49906525475d87a3a44 upstream. + +When running as a Xen PV dom0 the system needs to map ACPI data of the +host using host physical addresses, while those addresses can conflict +with the guest physical addresses of the loaded linux kernel. The same +problem might apply in case a PV guest is configured to use the host +memory map. + +This conflict can be solved by mapping the ACPI data to a different +guest physical address, but mapping the data via acpi_os_ioremap() +must still be possible using the host physical address, as this +address might be generated by AML when referencing some of the ACPI +data. + +When configured to support running as a Xen PV domain, have an +implementation of acpi_os_ioremap() being aware of the possibility to +need above mentioned translation of a host physical address to the +guest physical address. + +This modification requires to #include linux/acpi.h in some sources +which need to include asm/acpi.h directly. + +Signed-off-by: Juergen Gross +Reviewed-by: Jan Beulich +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/acpi.h | 8 ++++++++ + arch/x86/kernel/acpi/boot.c | 11 +++++++++++ + arch/x86/kernel/jailhouse.c | 1 + + arch/x86/kernel/mmconf-fam10h_64.c | 1 + + arch/x86/kernel/smpboot.c | 1 + + arch/x86/kernel/x86_init.c | 1 + + arch/x86/xen/p2m.c | 35 +++++++++++++++++++++++++++++++++++ + arch/x86/xen/setup.c | 2 +- + 8 files changed, 59 insertions(+), 1 deletion(-) + +--- a/arch/x86/include/asm/acpi.h ++++ b/arch/x86/include/asm/acpi.h +@@ -165,6 +165,14 @@ void acpi_generic_reduced_hw_init(void); + void x86_default_set_root_pointer(u64 addr); + u64 x86_default_get_root_pointer(void); + ++#ifdef CONFIG_XEN_PV ++/* A Xen PV domain needs a special acpi_os_ioremap() handling. */ ++extern void __iomem * (*acpi_os_ioremap)(acpi_physical_address phys, ++ acpi_size size); ++void __iomem *x86_acpi_os_ioremap(acpi_physical_address phys, acpi_size size); ++#define acpi_os_ioremap acpi_os_ioremap ++#endif ++ + #else /* !CONFIG_ACPI */ + + #define acpi_lapic 0 +--- a/arch/x86/kernel/acpi/boot.c ++++ b/arch/x86/kernel/acpi/boot.c +@@ -1901,3 +1901,14 @@ u64 x86_default_get_root_pointer(void) + { + return boot_params.acpi_rsdp_addr; + } ++ ++#ifdef CONFIG_XEN_PV ++void __iomem *x86_acpi_os_ioremap(acpi_physical_address phys, acpi_size size) ++{ ++ return ioremap_cache(phys, size); ++} ++ ++void __iomem * (*acpi_os_ioremap)(acpi_physical_address phys, acpi_size size) = ++ x86_acpi_os_ioremap; ++EXPORT_SYMBOL_GPL(acpi_os_ioremap); ++#endif +--- a/arch/x86/kernel/jailhouse.c ++++ b/arch/x86/kernel/jailhouse.c +@@ -12,6 +12,7 @@ + #include + #include + #include ++#include + #include + #include + #include +--- a/arch/x86/kernel/mmconf-fam10h_64.c ++++ b/arch/x86/kernel/mmconf-fam10h_64.c +@@ -9,6 +9,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/kernel/smpboot.c ++++ b/arch/x86/kernel/smpboot.c +@@ -60,6 +60,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/kernel/x86_init.c ++++ b/arch/x86/kernel/x86_init.c +@@ -8,6 +8,7 @@ + #include + #include + #include ++#include + + #include + #include +--- a/arch/x86/xen/p2m.c ++++ b/arch/x86/xen/p2m.c +@@ -70,6 +70,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -836,6 +837,34 @@ void __init xen_do_remap_nonram(void) + pr_info("Remapped %u non-RAM page(s)\n", remapped); + } + ++#ifdef CONFIG_ACPI ++/* ++ * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM ++ * regions into account. ++ * Any attempt to map an area crossing a remap boundary will produce a ++ * WARN() splat. ++ * phys is related to remap->maddr on input and will be rebased to remap->paddr. ++ */ ++static void __iomem *xen_acpi_os_ioremap(acpi_physical_address phys, ++ acpi_size size) ++{ ++ unsigned int i; ++ const struct nonram_remap *remap = xen_nonram_remap; ++ ++ for (i = 0; i < nr_nonram_remap; i++) { ++ if (phys + size > remap->maddr && ++ phys < remap->maddr + remap->size) { ++ WARN_ON(phys < remap->maddr || ++ phys + size > remap->maddr + remap->size); ++ phys += remap->paddr - remap->maddr; ++ break; ++ } ++ } ++ ++ return x86_acpi_os_ioremap(phys, size); ++} ++#endif /* CONFIG_ACPI */ ++ + /* + * Add a new non-RAM remap entry. + * In case of no free entry found, just crash the system. +@@ -850,6 +879,12 @@ void __init xen_add_remap_nonram(phys_ad + BUG(); + } + ++#ifdef CONFIG_ACPI ++ /* Switch to the Xen acpi_os_ioremap() variant. */ ++ if (nr_nonram_remap == 0) ++ acpi_os_ioremap = xen_acpi_os_ioremap; ++#endif ++ + xen_nonram_remap[nr_nonram_remap].maddr = maddr; + xen_nonram_remap[nr_nonram_remap].paddr = paddr; + xen_nonram_remap[nr_nonram_remap].size = size; +--- a/arch/x86/xen/setup.c ++++ b/arch/x86/xen/setup.c +@@ -15,12 +15,12 @@ + #include + #include + #include ++#include + + #include + #include + #include + #include +-#include + #include + #include + #include diff --git a/queue-6.6/xen-move-checks-for-e820-conflicts-further-up.patch b/queue-6.6/xen-move-checks-for-e820-conflicts-further-up.patch new file mode 100644 index 00000000000..0e42ed7fa47 --- /dev/null +++ b/queue-6.6/xen-move-checks-for-e820-conflicts-further-up.patch @@ -0,0 +1,86 @@ +From c4498ae316da5b5786ccd448fc555f3339b8e4ca Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Tue, 6 Aug 2024 09:56:48 +0200 +Subject: xen: move checks for e820 conflicts further up +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Juergen Gross + +commit c4498ae316da5b5786ccd448fc555f3339b8e4ca upstream. + +Move the checks for e820 memory map conflicts using the +xen_chk_is_e820_usable() helper further up in order to prepare +resolving some of the possible conflicts by doing some e820 map +modifications, which must happen before evaluating the RAM layout. + +Signed-off-by: Juergen Gross +Tested-by: Marek Marczykowski-Górecki +Reviewed-by: Jan Beulich +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/xen/setup.c | 44 ++++++++++++++++++++++---------------------- + 1 file changed, 22 insertions(+), 22 deletions(-) + +--- a/arch/x86/xen/setup.c ++++ b/arch/x86/xen/setup.c +@@ -855,6 +855,28 @@ char * __init xen_memory_setup(void) + /* Make sure the Xen-supplied memory map is well-ordered. */ + e820__update_table(&xen_e820_table); + ++ /* ++ * Check whether the kernel itself conflicts with the target E820 map. ++ * Failing now is better than running into weird problems later due ++ * to relocating (and even reusing) pages with kernel text or data. ++ */ ++ xen_chk_is_e820_usable(__pa_symbol(_text), ++ __pa_symbol(_end) - __pa_symbol(_text), ++ "kernel"); ++ ++ /* ++ * Check for a conflict of the xen_start_info memory with the target ++ * E820 map. ++ */ ++ xen_chk_is_e820_usable(__pa(xen_start_info), sizeof(*xen_start_info), ++ "xen_start_info"); ++ ++ /* ++ * Check for a conflict of the hypervisor supplied page tables with ++ * the target E820 map. ++ */ ++ xen_pt_check_e820(); ++ + max_pages = xen_get_max_pages(); + + /* How many extra pages do we need due to remapping? */ +@@ -927,28 +949,6 @@ char * __init xen_memory_setup(void) + + e820__update_table(e820_table); + +- /* +- * Check whether the kernel itself conflicts with the target E820 map. +- * Failing now is better than running into weird problems later due +- * to relocating (and even reusing) pages with kernel text or data. +- */ +- xen_chk_is_e820_usable(__pa_symbol(_text), +- __pa_symbol(_end) - __pa_symbol(_text), +- "kernel"); +- +- /* +- * Check for a conflict of the xen_start_info memory with the target +- * E820 map. +- */ +- xen_chk_is_e820_usable(__pa(xen_start_info), sizeof(*xen_start_info), +- "xen_start_info"); +- +- /* +- * Check for a conflict of the hypervisor supplied page tables with +- * the target E820 map. +- */ +- xen_pt_check_e820(); +- + xen_reserve_xen_mfnlist(); + + /* Check for a conflict of the initrd with the target E820 map. */