From: Greg Kroah-Hartman Date: Tue, 7 Feb 2023 09:02:35 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v5.15.93~35 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d4af777b1329b721c59b7ab006ac553dac7bd79c;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch mm-hugetlb-proc-check-for-hugetlb-shared-pmd-in-proc-pid-smaps.patch mm-memcg-fix-null-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch mm-multi-gen-lru-fix-crash-during-cgroup-migration.patch revert-mm-kmemleak-alloc-gray-object-for-reserved-region-with-direct-map.patch usb-gadget-f_uac2-fix-incorrect-increment-of-bnumendpoints.patch usb-gadget-udc-do-not-clear-gadget-driver.bus.patch usb-typec-ucsi-don-t-attempt-to-resume-the-ports-before-they-exist.patch x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch --- diff --git a/queue-6.1/hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch b/queue-6.1/hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch new file mode 100644 index 00000000000..c33b18c6002 --- /dev/null +++ b/queue-6.1/hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch @@ -0,0 +1,38 @@ +From 6dfb0771429a63db8561d44147f2bb76f93e1c86 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Thu, 2 Feb 2023 15:09:18 +0100 +Subject: HV: hv_balloon: fix memory leak with using debugfs_lookup() + +From: Greg Kroah-Hartman + +commit 6dfb0771429a63db8561d44147f2bb76f93e1c86 upstream. + +When calling debugfs_lookup() the result must have dput() called on it, +otherwise the memory will leak over time. To make things simpler, just +call debugfs_lookup_and_remove() instead which handles all of the logic +at once. + +Cc: "K. Y. Srinivasan" +Cc: Haiyang Zhang +Cc: Wei Liu +Cc: Dexuan Cui +Fixes: d180e0a1be6c ("Drivers: hv: Create debugfs file with hyper-v balloon usage information") +Cc: stable +Reviewed-by: Michael Kelley +Link: https://lore.kernel.org/r/20230202140918.2289522-1-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hv/hv_balloon.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hv/hv_balloon.c ++++ b/drivers/hv/hv_balloon.c +@@ -1911,7 +1911,7 @@ static void hv_balloon_debugfs_init(str + + static void hv_balloon_debugfs_exit(struct hv_dynmem_device *b) + { +- debugfs_remove(debugfs_lookup("hv-balloon", NULL)); ++ debugfs_lookup_and_remove("hv-balloon", NULL); + } + + #else diff --git a/queue-6.1/kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch b/queue-6.1/kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch new file mode 100644 index 00000000000..978fa8d6354 --- /dev/null +++ b/queue-6.1/kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch @@ -0,0 +1,34 @@ +From d83d7ed260283560700d4034a80baad46620481b Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Thu, 2 Feb 2023 16:15:54 +0100 +Subject: kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() + +From: Greg Kroah-Hartman + +commit d83d7ed260283560700d4034a80baad46620481b upstream. + +When calling debugfs_lookup() the result must have dput() called on it, +otherwise the memory will leak over time. To make things simpler, just +call debugfs_lookup_and_remove() instead which handles all of the logic +at once. + +Cc: Thomas Gleixner +Cc: stable +Reviewed-by: Marc Zyngier +Link: https://lore.kernel.org/r/20230202151554.2310273-1-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/irq/irqdomain.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/irq/irqdomain.c ++++ b/kernel/irq/irqdomain.c +@@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struc + + static void debugfs_remove_domain_dir(struct irq_domain *d) + { +- debugfs_remove(debugfs_lookup(d->name, domain_dir)); ++ debugfs_lookup_and_remove(d->name, domain_dir); + } + + void __init irq_domain_debugfs_init(struct dentry *root) diff --git a/queue-6.1/mm-hugetlb-proc-check-for-hugetlb-shared-pmd-in-proc-pid-smaps.patch b/queue-6.1/mm-hugetlb-proc-check-for-hugetlb-shared-pmd-in-proc-pid-smaps.patch new file mode 100644 index 00000000000..0ccedf764fc --- /dev/null +++ b/queue-6.1/mm-hugetlb-proc-check-for-hugetlb-shared-pmd-in-proc-pid-smaps.patch @@ -0,0 +1,97 @@ +From 3489dbb696d25602aea8c3e669a6d43b76bd5358 Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +Date: Thu, 26 Jan 2023 14:27:20 -0800 +Subject: mm: hugetlb: proc: check for hugetlb shared PMD in /proc/PID/smaps + +From: Mike Kravetz + +commit 3489dbb696d25602aea8c3e669a6d43b76bd5358 upstream. + +Patch series "Fixes for hugetlb mapcount at most 1 for shared PMDs". + +This issue of mapcount in hugetlb pages referenced by shared PMDs was +discussed in [1]. The following two patches address user visible behavior +caused by this issue. + +[1] https://lore.kernel.org/linux-mm/Y9BF+OCdWnCSilEu@monkey/ + + +This patch (of 2): + +A hugetlb page will have a mapcount of 1 if mapped by multiple processes +via a shared PMD. This is because only the first process increases the +map count, and subsequent processes just add the shared PMD page to their +page table. + +page_mapcount is being used to decide if a hugetlb page is shared or +private in /proc/PID/smaps. Pages referenced via a shared PMD were +incorrectly being counted as private. + +To fix, check for a shared PMD if mapcount is 1. If a shared PMD is found +count the hugetlb page as shared. A new helper to check for a shared PMD +is added. + +[akpm@linux-foundation.org: simplification, per David] +[akpm@linux-foundation.org: hugetlb.h: include page_ref.h for page_count()] +Link: https://lkml.kernel.org/r/20230126222721.222195-2-mike.kravetz@oracle.com +Fixes: 25ee01a2fca0 ("mm: hugetlb: proc: add hugetlb-related fields to /proc/PID/smaps") +Signed-off-by: Mike Kravetz +Acked-by: Peter Xu +Cc: David Hildenbrand +Cc: James Houghton +Cc: Matthew Wilcox +Cc: Michal Hocko +Cc: Muchun Song +Cc: Naoya Horiguchi +Cc: Vishal Moola (Oracle) +Cc: Yang Shi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/task_mmu.c | 4 +--- + include/linux/hugetlb.h | 13 +++++++++++++ + 2 files changed, 14 insertions(+), 3 deletions(-) + +--- a/fs/proc/task_mmu.c ++++ b/fs/proc/task_mmu.c +@@ -737,9 +737,7 @@ static int smaps_hugetlb_range(pte_t *pt + page = pfn_swap_entry_to_page(swpent); + } + if (page) { +- int mapcount = page_mapcount(page); +- +- if (mapcount >= 2) ++ if (page_mapcount(page) >= 2 || hugetlb_pmd_shared(pte)) + mss->shared_hugetlb += huge_page_size(hstate_vma(vma)); + else + mss->private_hugetlb += huge_page_size(hstate_vma(vma)); +--- a/include/linux/hugetlb.h ++++ b/include/linux/hugetlb.h +@@ -7,6 +7,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -1182,6 +1183,18 @@ static inline __init void hugetlb_cma_re + } + #endif + ++#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE ++static inline bool hugetlb_pmd_shared(pte_t *pte) ++{ ++ return page_count(virt_to_page(pte)) > 1; ++} ++#else ++static inline bool hugetlb_pmd_shared(pte_t *pte) ++{ ++ return false; ++} ++#endif ++ + bool want_pmd_share(struct vm_area_struct *vma, unsigned long addr); + + #ifndef __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE diff --git a/queue-6.1/mm-memcg-fix-null-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch b/queue-6.1/mm-memcg-fix-null-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch new file mode 100644 index 00000000000..ba24722e5f6 --- /dev/null +++ b/queue-6.1/mm-memcg-fix-null-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch @@ -0,0 +1,53 @@ +From ac86f547ca1002aec2ef66b9e64d03f45bbbfbb9 Mon Sep 17 00:00:00 2001 +From: Kefeng Wang +Date: Sun, 29 Jan 2023 12:09:45 +0800 +Subject: mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() + +From: Kefeng Wang + +commit ac86f547ca1002aec2ef66b9e64d03f45bbbfbb9 upstream. + +As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"), +hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg +could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could +occurs a NULL pointer dereference, let's do not record the foreign +writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to +fix it. + +Link: https://lkml.kernel.org/r/20230129040945.180629-1-wangkefeng.wang@huawei.com +Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing") +Signed-off-by: Kefeng Wang +Reported-by: Ma Wupeng +Tested-by: Miko Larsson +Acked-by: Michal Hocko +Cc: Jan Kara +Cc: Jens Axboe +Cc: Kefeng Wang +Cc: Ma Wupeng +Cc: Naoya Horiguchi +Cc: Shakeel Butt +Cc: Tejun Heo +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/memcontrol.h | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/include/linux/memcontrol.h ++++ b/include/linux/memcontrol.h +@@ -1655,10 +1655,13 @@ void mem_cgroup_track_foreign_dirty_slow + static inline void mem_cgroup_track_foreign_dirty(struct folio *folio, + struct bdi_writeback *wb) + { ++ struct mem_cgroup *memcg; ++ + if (mem_cgroup_disabled()) + return; + +- if (unlikely(&folio_memcg(folio)->css != wb->memcg_css)) ++ memcg = folio_memcg(folio); ++ if (unlikely(memcg && &memcg->css != wb->memcg_css)) + mem_cgroup_track_foreign_dirty_slowpath(folio, wb); + } + diff --git a/queue-6.1/mm-multi-gen-lru-fix-crash-during-cgroup-migration.patch b/queue-6.1/mm-multi-gen-lru-fix-crash-during-cgroup-migration.patch new file mode 100644 index 00000000000..ce11e305b0a --- /dev/null +++ b/queue-6.1/mm-multi-gen-lru-fix-crash-during-cgroup-migration.patch @@ -0,0 +1,61 @@ +From de08eaa6156405f2e9369f06ba5afae0e4ab3b62 Mon Sep 17 00:00:00 2001 +From: Yu Zhao +Date: Sun, 15 Jan 2023 20:44:05 -0700 +Subject: mm: multi-gen LRU: fix crash during cgroup migration + +From: Yu Zhao + +commit de08eaa6156405f2e9369f06ba5afae0e4ab3b62 upstream. + +lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself. This +isn't true for the following scenario: + + CPU 1 CPU 2 + + clone() + cgroup_can_fork() + cgroup_procs_write() + cgroup_post_fork() + task_lock() + lru_gen_migrate_mm() + task_unlock() + task_lock() + lru_gen_add_mm() + task_unlock() + +And when the above happens, kernel crashes because of linked list +corruption (mm_struct->lru_gen.list). + +Link: https://lore.kernel.org/r/20230115134651.30028-1-msizanoen@qtmlabs.xyz/ +Link: https://lkml.kernel.org/r/20230116034405.2960276-1-yuzhao@google.com +Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks") +Signed-off-by: Yu Zhao +Reported-by: msizanoen +Tested-by: msizanoen +Cc: [6.1+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/vmscan.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -3290,13 +3290,16 @@ void lru_gen_migrate_mm(struct mm_struct + if (mem_cgroup_disabled()) + return; + ++ /* migration can happen before addition */ ++ if (!mm->lru_gen.memcg) ++ return; ++ + rcu_read_lock(); + memcg = mem_cgroup_from_task(task); + rcu_read_unlock(); + if (memcg == mm->lru_gen.memcg) + return; + +- VM_WARN_ON_ONCE(!mm->lru_gen.memcg); + VM_WARN_ON_ONCE(list_empty(&mm->lru_gen.list)); + + lru_gen_del_mm(mm); diff --git a/queue-6.1/revert-mm-kmemleak-alloc-gray-object-for-reserved-region-with-direct-map.patch b/queue-6.1/revert-mm-kmemleak-alloc-gray-object-for-reserved-region-with-direct-map.patch new file mode 100644 index 00000000000..a2ec7e50034 --- /dev/null +++ b/queue-6.1/revert-mm-kmemleak-alloc-gray-object-for-reserved-region-with-direct-map.patch @@ -0,0 +1,61 @@ +From 8ef852f1cb426a5812aee700d3b4297aaa426acc Mon Sep 17 00:00:00 2001 +From: "Isaac J. Manjarres" +Date: Tue, 24 Jan 2023 15:02:54 -0800 +Subject: Revert "mm: kmemleak: alloc gray object for reserved region with direct map" + +From: Isaac J. Manjarres + +commit 8ef852f1cb426a5812aee700d3b4297aaa426acc upstream. + +This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. + +Kmemleak operates by periodically scanning memory regions for pointers to +allocated memory blocks to determine if they are leaked or not. However, +reserved memory regions can be used for DMA transactions between a device +and a CPU, and thus, wouldn't contain pointers to allocated memory blocks, +making them inappropriate for kmemleak to scan. Thus, revert this commit. + +Link: https://lkml.kernel.org/r/20230124230254.295589-1-isaacmanjarres@google.com +Fixes: 972fa3a7c17c9 ("mm: kmemleak: alloc gray object for reserved region with direct map") +Signed-off-by: Isaac J. Manjarres +Acked-by: Catalin Marinas +Cc: Calvin Zhang +Cc: Frank Rowand +Cc: Rob Herring +Cc: Saravana Kannan +Cc: [5.17+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + drivers/of/fdt.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c +index f08b25195ae7..d1a68b6d03b3 100644 +--- a/drivers/of/fdt.c ++++ b/drivers/of/fdt.c +@@ -26,7 +26,6 @@ + #include + #include + #include +-#include + + #include /* for COMMAND_LINE_SIZE */ + #include +@@ -525,12 +524,9 @@ static int __init __reserved_mem_reserve_reg(unsigned long node, + size = dt_mem_next_cell(dt_root_size_cells, &prop); + + if (size && +- early_init_dt_reserve_memory(base, size, nomap) == 0) { ++ early_init_dt_reserve_memory(base, size, nomap) == 0) + pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %lu MiB\n", + uname, &base, (unsigned long)(size / SZ_1M)); +- if (!nomap) +- kmemleak_alloc_phys(base, size, 0); +- } + else + pr_err("Reserved memory: failed to reserve memory for node '%s': base %pa, size %lu MiB\n", + uname, &base, (unsigned long)(size / SZ_1M)); +-- +2.39.1 + diff --git a/queue-6.1/series b/queue-6.1/series index c4a8951f7e9..95636081f16 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -152,3 +152,13 @@ parisc-fix-return-code-of-pdc_iodc_print.patch parisc-replace-hardcoded-value-with-priv_user-constant-in-ptrace.c.patch parisc-wire-up-ptrace_getregs-ptrace_setregs-for-compat-case.patch riscv-disable-generation-of-unwind-tables.patch +revert-mm-kmemleak-alloc-gray-object-for-reserved-region-with-direct-map.patch +mm-multi-gen-lru-fix-crash-during-cgroup-migration.patch +mm-hugetlb-proc-check-for-hugetlb-shared-pmd-in-proc-pid-smaps.patch +mm-memcg-fix-null-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch +usb-gadget-f_uac2-fix-incorrect-increment-of-bnumendpoints.patch +usb-typec-ucsi-don-t-attempt-to-resume-the-ports-before-they-exist.patch +usb-gadget-udc-do-not-clear-gadget-driver.bus.patch +kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch +hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch +x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch diff --git a/queue-6.1/usb-gadget-f_uac2-fix-incorrect-increment-of-bnumendpoints.patch b/queue-6.1/usb-gadget-f_uac2-fix-incorrect-increment-of-bnumendpoints.patch new file mode 100644 index 00000000000..d478369a1bb --- /dev/null +++ b/queue-6.1/usb-gadget-f_uac2-fix-incorrect-increment-of-bnumendpoints.patch @@ -0,0 +1,38 @@ +From 2fa89458af9993fab8054daf827f38881e2ad473 Mon Sep 17 00:00:00 2001 +From: Pratham Pratap +Date: Wed, 25 Jan 2023 12:57:25 +0530 +Subject: usb: gadget: f_uac2: Fix incorrect increment of bNumEndpoints + +From: Pratham Pratap + +commit 2fa89458af9993fab8054daf827f38881e2ad473 upstream. + +Currently connect/disconnect of USB cable calls afunc_bind and +eventually increments the bNumEndpoints. Performing multiple +plugin/plugout will increment bNumEndpoints incorrectly, and on +the next plug-in it leads to invalid configuration of descriptor +and hence enumeration fails. + +Fix this by resetting the value of bNumEndpoints to 1 on every +afunc_bind call. + +Fixes: 40c73b30546e ("usb: gadget: f_uac2: add adaptive sync support for capture") +Cc: stable +Signed-off-by: Pratham Pratap +Signed-off-by: Prashanth K +Link: https://lore.kernel.org/r/1674631645-28888-1-git-send-email-quic_prashk@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/f_uac2.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/gadget/function/f_uac2.c ++++ b/drivers/usb/gadget/function/f_uac2.c +@@ -1142,6 +1142,7 @@ afunc_bind(struct usb_configuration *cfg + } + std_as_out_if0_desc.bInterfaceNumber = ret; + std_as_out_if1_desc.bInterfaceNumber = ret; ++ std_as_out_if1_desc.bNumEndpoints = 1; + uac2->as_out_intf = ret; + uac2->as_out_alt = 0; + diff --git a/queue-6.1/usb-gadget-udc-do-not-clear-gadget-driver.bus.patch b/queue-6.1/usb-gadget-udc-do-not-clear-gadget-driver.bus.patch new file mode 100644 index 00000000000..906164e232b --- /dev/null +++ b/queue-6.1/usb-gadget-udc-do-not-clear-gadget-driver.bus.patch @@ -0,0 +1,202 @@ +From 30d09b3131f5b1b9d54ad9b7ee171a45e21362b3 Mon Sep 17 00:00:00 2001 +From: Aaro Koskinen +Date: Thu, 2 Feb 2023 00:01:25 +0200 +Subject: usb: gadget: udc: do not clear gadget driver.bus + +From: Aaro Koskinen + +commit 30d09b3131f5b1b9d54ad9b7ee171a45e21362b3 upstream. + +Before the commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") +gadget driver.bus was unused. For whatever reason, many UDC drivers set +this field explicitly to NULL in udc_start(). With the newly added gadget +bus, doing this will crash the driver during the attach. + +The problem was first reported, fixed and tested with OMAP UDC and g_ether. +Other drivers are changed based on code analysis only. + +Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") +Cc: stable +Signed-off-by: Aaro Koskinen +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20230201220125.GD2415@darkstar.musicnaut.iki.fi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/udc/bcm63xx_udc.c | 1 - + drivers/usb/gadget/udc/fotg210-udc.c | 1 - + drivers/usb/gadget/udc/fsl_qe_udc.c | 1 - + drivers/usb/gadget/udc/fsl_udc_core.c | 1 - + drivers/usb/gadget/udc/fusb300_udc.c | 1 - + drivers/usb/gadget/udc/goku_udc.c | 1 - + drivers/usb/gadget/udc/gr_udc.c | 1 - + drivers/usb/gadget/udc/m66592-udc.c | 1 - + drivers/usb/gadget/udc/max3420_udc.c | 1 - + drivers/usb/gadget/udc/mv_u3d_core.c | 1 - + drivers/usb/gadget/udc/mv_udc_core.c | 1 - + drivers/usb/gadget/udc/net2272.c | 1 - + drivers/usb/gadget/udc/net2280.c | 1 - + drivers/usb/gadget/udc/omap_udc.c | 1 - + drivers/usb/gadget/udc/pch_udc.c | 1 - + drivers/usb/gadget/udc/snps_udc_core.c | 1 - + 16 files changed, 16 deletions(-) + +--- a/drivers/usb/gadget/udc/bcm63xx_udc.c ++++ b/drivers/usb/gadget/udc/bcm63xx_udc.c +@@ -1830,7 +1830,6 @@ static int bcm63xx_udc_start(struct usb_ + bcm63xx_select_phy_mode(udc, true); + + udc->driver = driver; +- driver->driver.bus = NULL; + udc->gadget.dev.of_node = udc->dev->of_node; + + spin_unlock_irqrestore(&udc->lock, flags); +--- a/drivers/usb/gadget/udc/fotg210-udc.c ++++ b/drivers/usb/gadget/udc/fotg210-udc.c +@@ -1009,7 +1009,6 @@ static int fotg210_udc_start(struct usb_ + u32 value; + + /* hook up the driver */ +- driver->driver.bus = NULL; + fotg210->driver = driver; + + /* enable device global interrupt */ +--- a/drivers/usb/gadget/udc/fsl_qe_udc.c ++++ b/drivers/usb/gadget/udc/fsl_qe_udc.c +@@ -2285,7 +2285,6 @@ static int fsl_qe_start(struct usb_gadge + /* lock is needed but whether should use this lock or another */ + spin_lock_irqsave(&udc->lock, flags); + +- driver->driver.bus = NULL; + /* hook up the driver */ + udc->driver = driver; + udc->gadget.speed = driver->max_speed; +--- a/drivers/usb/gadget/udc/fsl_udc_core.c ++++ b/drivers/usb/gadget/udc/fsl_udc_core.c +@@ -1943,7 +1943,6 @@ static int fsl_udc_start(struct usb_gadg + /* lock is needed but whether should use this lock or another */ + spin_lock_irqsave(&udc_controller->lock, flags); + +- driver->driver.bus = NULL; + /* hook up the driver */ + udc_controller->driver = driver; + spin_unlock_irqrestore(&udc_controller->lock, flags); +--- a/drivers/usb/gadget/udc/fusb300_udc.c ++++ b/drivers/usb/gadget/udc/fusb300_udc.c +@@ -1311,7 +1311,6 @@ static int fusb300_udc_start(struct usb_ + struct fusb300 *fusb300 = to_fusb300(g); + + /* hook up the driver */ +- driver->driver.bus = NULL; + fusb300->driver = driver; + + return 0; +--- a/drivers/usb/gadget/udc/goku_udc.c ++++ b/drivers/usb/gadget/udc/goku_udc.c +@@ -1375,7 +1375,6 @@ static int goku_udc_start(struct usb_gad + struct goku_udc *dev = to_goku_udc(g); + + /* hook up the driver */ +- driver->driver.bus = NULL; + dev->driver = driver; + + /* +--- a/drivers/usb/gadget/udc/gr_udc.c ++++ b/drivers/usb/gadget/udc/gr_udc.c +@@ -1906,7 +1906,6 @@ static int gr_udc_start(struct usb_gadge + spin_lock(&dev->lock); + + /* Hook up the driver */ +- driver->driver.bus = NULL; + dev->driver = driver; + + /* Get ready for host detection */ +--- a/drivers/usb/gadget/udc/m66592-udc.c ++++ b/drivers/usb/gadget/udc/m66592-udc.c +@@ -1454,7 +1454,6 @@ static int m66592_udc_start(struct usb_g + struct m66592 *m66592 = to_m66592(g); + + /* hook up the driver */ +- driver->driver.bus = NULL; + m66592->driver = driver; + + m66592_bset(m66592, M66592_VBSE | M66592_URST, M66592_INTENB0); +--- a/drivers/usb/gadget/udc/max3420_udc.c ++++ b/drivers/usb/gadget/udc/max3420_udc.c +@@ -1108,7 +1108,6 @@ static int max3420_udc_start(struct usb_ + + spin_lock_irqsave(&udc->lock, flags); + /* hook up the driver */ +- driver->driver.bus = NULL; + udc->driver = driver; + udc->gadget.speed = USB_SPEED_FULL; + +--- a/drivers/usb/gadget/udc/mv_u3d_core.c ++++ b/drivers/usb/gadget/udc/mv_u3d_core.c +@@ -1243,7 +1243,6 @@ static int mv_u3d_start(struct usb_gadge + } + + /* hook up the driver ... */ +- driver->driver.bus = NULL; + u3d->driver = driver; + + u3d->ep0_dir = USB_DIR_OUT; +--- a/drivers/usb/gadget/udc/mv_udc_core.c ++++ b/drivers/usb/gadget/udc/mv_udc_core.c +@@ -1359,7 +1359,6 @@ static int mv_udc_start(struct usb_gadge + spin_lock_irqsave(&udc->lock, flags); + + /* hook up the driver ... */ +- driver->driver.bus = NULL; + udc->driver = driver; + + udc->usb_state = USB_STATE_ATTACHED; +--- a/drivers/usb/gadget/udc/net2272.c ++++ b/drivers/usb/gadget/udc/net2272.c +@@ -1451,7 +1451,6 @@ static int net2272_start(struct usb_gadg + dev->ep[i].irqs = 0; + /* hook up the driver ... */ + dev->softconnect = 1; +- driver->driver.bus = NULL; + dev->driver = driver; + + /* ... then enable host detection and ep0; and we're ready +--- a/drivers/usb/gadget/udc/net2280.c ++++ b/drivers/usb/gadget/udc/net2280.c +@@ -2423,7 +2423,6 @@ static int net2280_start(struct usb_gadg + dev->ep[i].irqs = 0; + + /* hook up the driver ... */ +- driver->driver.bus = NULL; + dev->driver = driver; + + retval = device_create_file(&dev->pdev->dev, &dev_attr_function); +--- a/drivers/usb/gadget/udc/omap_udc.c ++++ b/drivers/usb/gadget/udc/omap_udc.c +@@ -2066,7 +2066,6 @@ static int omap_udc_start(struct usb_gad + udc->softconnect = 1; + + /* hook up the driver */ +- driver->driver.bus = NULL; + udc->driver = driver; + spin_unlock_irqrestore(&udc->lock, flags); + +--- a/drivers/usb/gadget/udc/pch_udc.c ++++ b/drivers/usb/gadget/udc/pch_udc.c +@@ -2908,7 +2908,6 @@ static int pch_udc_start(struct usb_gadg + { + struct pch_udc_dev *dev = to_pch_udc(g); + +- driver->driver.bus = NULL; + dev->driver = driver; + + /* get ready for ep0 traffic */ +--- a/drivers/usb/gadget/udc/snps_udc_core.c ++++ b/drivers/usb/gadget/udc/snps_udc_core.c +@@ -1933,7 +1933,6 @@ static int amd5536_udc_start(struct usb_ + struct udc *dev = to_amd5536_udc(g); + u32 tmp; + +- driver->driver.bus = NULL; + dev->driver = driver; + + /* Some gadget drivers use both ep0 directions. diff --git a/queue-6.1/usb-typec-ucsi-don-t-attempt-to-resume-the-ports-before-they-exist.patch b/queue-6.1/usb-typec-ucsi-don-t-attempt-to-resume-the-ports-before-they-exist.patch new file mode 100644 index 00000000000..eca656ad4cb --- /dev/null +++ b/queue-6.1/usb-typec-ucsi-don-t-attempt-to-resume-the-ports-before-they-exist.patch @@ -0,0 +1,55 @@ +From f82060da749c611ed427523b6d1605d87338aac1 Mon Sep 17 00:00:00 2001 +From: Heikki Krogerus +Date: Tue, 31 Jan 2023 16:15:18 +0200 +Subject: usb: typec: ucsi: Don't attempt to resume the ports before they exist + +From: Heikki Krogerus + +commit f82060da749c611ed427523b6d1605d87338aac1 upstream. + +This will fix null pointer dereference that was caused by +the driver attempting to resume ports that were not yet +registered. + +Fixes: e0dced9c7d47 ("usb: typec: ucsi: Resume in separate work") +Cc: +Link: https://bugzilla.kernel.org/show_bug.cgi?id=216697 +Signed-off-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20230131141518.78215-1-heikki.krogerus@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/ucsi/ucsi.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/usb/typec/ucsi/ucsi.c ++++ b/drivers/usb/typec/ucsi/ucsi.c +@@ -1269,6 +1269,9 @@ err_unregister: + con->port = NULL; + } + ++ kfree(ucsi->connector); ++ ucsi->connector = NULL; ++ + err_reset: + memset(&ucsi->cap, 0, sizeof(ucsi->cap)); + ucsi_reset_ppm(ucsi); +@@ -1300,7 +1303,8 @@ static void ucsi_resume_work(struct work + + int ucsi_resume(struct ucsi *ucsi) + { +- queue_work(system_long_wq, &ucsi->resume_work); ++ if (ucsi->connector) ++ queue_work(system_long_wq, &ucsi->resume_work); + return 0; + } + EXPORT_SYMBOL_GPL(ucsi_resume); +@@ -1420,6 +1424,9 @@ void ucsi_unregister(struct ucsi *ucsi) + /* Disable notifications */ + ucsi->ops->async_write(ucsi, UCSI_CONTROL, &cmd, sizeof(cmd)); + ++ if (!ucsi->connector) ++ return; ++ + for (i = 0; i < ucsi->cap.num_connectors; i++) { + cancel_work_sync(&ucsi->connector[i].work); + ucsi_unregister_partner(&ucsi->connector[i]); diff --git a/queue-6.1/x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch b/queue-6.1/x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch new file mode 100644 index 00000000000..7bb87a58cc1 --- /dev/null +++ b/queue-6.1/x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch @@ -0,0 +1,80 @@ +From 9d2c7203ffdb846399b82b0660563c89e918c751 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Tue, 31 Jan 2023 09:57:18 +0100 +Subject: x86/debug: Fix stack recursion caused by wrongly ordered DR7 accesses + +From: Joerg Roedel + +commit 9d2c7203ffdb846399b82b0660563c89e918c751 upstream. + +In kernels compiled with CONFIG_PARAVIRT=n, the compiler re-orders the +DR7 read in exc_nmi() to happen before the call to sev_es_ist_enter(). + +This is problematic when running as an SEV-ES guest because in this +environment the DR7 read might cause a #VC exception, and taking #VC +exceptions is not safe in exc_nmi() before sev_es_ist_enter() has run. + +The result is stack recursion if the NMI was caused on the #VC IST +stack, because a subsequent #VC exception in the NMI handler will +overwrite the stack frame of the interrupted #VC handler. + +As there are no compiler barriers affecting the ordering of DR7 +reads/writes, make the accesses to this register volatile, forbidding +the compiler to re-order them. + + [ bp: Massage text, make them volatile too, to make sure some + aggressive compiler optimization pass doesn't discard them. ] + +Fixes: 315562c9af3d ("x86/sev-es: Adjust #VC IST Stack on entering NMI handler") +Reported-by: Alexey Kardashevskiy +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230127035616.508966-1-aik@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/debugreg.h | 26 ++++++++++++++++++++++++-- + 1 file changed, 24 insertions(+), 2 deletions(-) + +--- a/arch/x86/include/asm/debugreg.h ++++ b/arch/x86/include/asm/debugreg.h +@@ -39,7 +39,20 @@ static __always_inline unsigned long nat + asm("mov %%db6, %0" :"=r" (val)); + break; + case 7: +- asm("mov %%db7, %0" :"=r" (val)); ++ /* ++ * Apply __FORCE_ORDER to DR7 reads to forbid re-ordering them ++ * with other code. ++ * ++ * This is needed because a DR7 access can cause a #VC exception ++ * when running under SEV-ES. Taking a #VC exception is not a ++ * safe thing to do just anywhere in the entry code and ++ * re-ordering might place the access into an unsafe location. ++ * ++ * This happened in the NMI handler, where the DR7 read was ++ * re-ordered to happen before the call to sev_es_ist_enter(), ++ * causing stack recursion. ++ */ ++ asm volatile("mov %%db7, %0" : "=r" (val) : __FORCE_ORDER); + break; + default: + BUG(); +@@ -66,7 +79,16 @@ static __always_inline void native_set_d + asm("mov %0, %%db6" ::"r" (value)); + break; + case 7: +- asm("mov %0, %%db7" ::"r" (value)); ++ /* ++ * Apply __FORCE_ORDER to DR7 writes to forbid re-ordering them ++ * with other code. ++ * ++ * While is didn't happen with a DR7 write (see the DR7 read ++ * comment above which explains where it happened), add the ++ * __FORCE_ORDER here too to avoid similar problems in the ++ * future. ++ */ ++ asm volatile("mov %0, %%db7" ::"r" (value), __FORCE_ORDER); + break; + default: + BUG();