From: Greg Kroah-Hartman Date: Sat, 17 Jan 2026 15:03:22 +0000 (+0100) Subject: drop some patches X-Git-Tag: v6.6.121~6 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9ccd59530ac091053835b45a6f7050cb12b74412;p=thirdparty%2Fkernel%2Fstable-queue.git drop some patches --- diff --git a/queue-5.10/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch b/queue-5.10/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch deleted file mode 100644 index eeda24e20d..0000000000 --- a/queue-5.10/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch +++ /dev/null @@ -1,170 +0,0 @@ -From 99537d5c476cada9cf75aef9fa75579a31faadb9 Mon Sep 17 00:00:00 2001 -From: Xiaolei Wang -Date: Mon, 22 Dec 2025 09:56:24 +0800 -Subject: net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open() - -From: Xiaolei Wang - -commit 99537d5c476cada9cf75aef9fa75579a31faadb9 upstream. - -In the non-RT kernel, local_bh_disable() merely disables preemption, -whereas it maps to an actual spin lock in the RT kernel. Consequently, -when attempting to refill RX buffers via netdev_alloc_skb() in -macb_mac_link_up(), a deadlock scenario arises as follows: - - WARNING: possible circular locking dependency detected - 6.18.0-08691-g2061f18ad76e #39 Not tainted - ------------------------------------------------------ - kworker/0:0/8 is trying to acquire lock: - ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c - - but task is already holding lock: - ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit - +0x148/0xb7c - - which lock already depends on the new lock. - - the existing dependency chain (in reverse order) is: - - -> #3 (&queue->tx_ptr_lock){+...}-{3:3}: - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x148/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #2 (_xmit_ETHER#2){+...}-{3:3}: - rt_spin_lock+0x50/0x1f0 - sch_direct_xmit+0x11c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}: - lock_release+0x250/0x348 - __local_bh_enable_ip+0x7c/0x240 - __netdev_alloc_skb+0x1b4/0x1d8 - gem_rx_refill+0xdc/0x240 - gem_init_rings+0xb4/0x108 - macb_mac_link_up+0x9c/0x2b4 - phylink_resolve+0x170/0x614 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #0 (&bp->lock){+.+.}-{3:3}: - __lock_acquire+0x15a8/0x2084 - lock_acquire+0x1cc/0x350 - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x808/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - other info that might help us debug this: - - Chain exists of: - &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock - - Possible unsafe locking scenario: - - CPU0 CPU1 - ---- ---- - lock(&queue->tx_ptr_lock); - lock(_xmit_ETHER#2); - lock(&queue->tx_ptr_lock); - lock(&bp->lock); - - *** DEADLOCK *** - - Call trace: - show_stack+0x18/0x24 (C) - dump_stack_lvl+0xa0/0xf0 - dump_stack+0x18/0x24 - print_circular_bug+0x28c/0x370 - check_noncircular+0x198/0x1ac - __lock_acquire+0x15a8/0x2084 - lock_acquire+0x1cc/0x350 - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x808/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - -Notably, invoking the mog_init_rings() callback upon link establishment -is unnecessary. Instead, we can exclusively call mog_init_rings() within -the ndo_open() callback. This adjustment resolves the deadlock issue. -Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings() -when opening the network interface via at91ether_open(), moving -mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC -check. - -Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()") -Cc: stable@vger.kernel.org -Suggested-by: Kevin Hao -Signed-off-by: Xiaolei Wang -Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com -Signed-off-by: Paolo Abeni -Signed-off-by: Greg Kroah-Hartman ---- - drivers/net/ethernet/cadence/macb_main.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - ---- a/drivers/net/ethernet/cadence/macb_main.c -+++ b/drivers/net/ethernet/cadence/macb_main.c -@@ -654,7 +654,6 @@ static void macb_mac_link_up(struct phyl - /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down - * cleared the pipeline and control registers. - */ -- bp->macbgem_ops.mog_init_rings(bp); - macb_init_buffers(bp); - - for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) -@@ -2287,6 +2286,8 @@ static void gem_init_rings(struct macb * - unsigned int q; - int i; - -+ bp->macbgem_ops.mog_init_rings(bp); -+ - for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) { - for (i = 0; i < bp->tx_ring_size; i++) { - desc = macb_tx_desc(queue, i); diff --git a/queue-5.10/series b/queue-5.10/series index 256ed886f4..1803d9324d 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -332,7 +332,6 @@ fjes-add-missing-iounmap-in-fjes_hw_init.patch nfsd-drop-the-client-reference-in-client_states_open.patch net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch -net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch rdma-core-fix-kasan-slab-use-after-free-read-in-ib_register_device-problem.patch diff --git a/queue-5.15/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch b/queue-5.15/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch deleted file mode 100644 index b779d3d7b8..0000000000 --- a/queue-5.15/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch +++ /dev/null @@ -1,170 +0,0 @@ -From 99537d5c476cada9cf75aef9fa75579a31faadb9 Mon Sep 17 00:00:00 2001 -From: Xiaolei Wang -Date: Mon, 22 Dec 2025 09:56:24 +0800 -Subject: net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open() - -From: Xiaolei Wang - -commit 99537d5c476cada9cf75aef9fa75579a31faadb9 upstream. - -In the non-RT kernel, local_bh_disable() merely disables preemption, -whereas it maps to an actual spin lock in the RT kernel. Consequently, -when attempting to refill RX buffers via netdev_alloc_skb() in -macb_mac_link_up(), a deadlock scenario arises as follows: - - WARNING: possible circular locking dependency detected - 6.18.0-08691-g2061f18ad76e #39 Not tainted - ------------------------------------------------------ - kworker/0:0/8 is trying to acquire lock: - ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c - - but task is already holding lock: - ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit - +0x148/0xb7c - - which lock already depends on the new lock. - - the existing dependency chain (in reverse order) is: - - -> #3 (&queue->tx_ptr_lock){+...}-{3:3}: - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x148/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #2 (_xmit_ETHER#2){+...}-{3:3}: - rt_spin_lock+0x50/0x1f0 - sch_direct_xmit+0x11c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}: - lock_release+0x250/0x348 - __local_bh_enable_ip+0x7c/0x240 - __netdev_alloc_skb+0x1b4/0x1d8 - gem_rx_refill+0xdc/0x240 - gem_init_rings+0xb4/0x108 - macb_mac_link_up+0x9c/0x2b4 - phylink_resolve+0x170/0x614 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - -> #0 (&bp->lock){+.+.}-{3:3}: - __lock_acquire+0x15a8/0x2084 - lock_acquire+0x1cc/0x350 - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x808/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - - other info that might help us debug this: - - Chain exists of: - &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock - - Possible unsafe locking scenario: - - CPU0 CPU1 - ---- ---- - lock(&queue->tx_ptr_lock); - lock(_xmit_ETHER#2); - lock(&queue->tx_ptr_lock); - lock(&bp->lock); - - *** DEADLOCK *** - - Call trace: - show_stack+0x18/0x24 (C) - dump_stack_lvl+0xa0/0xf0 - dump_stack+0x18/0x24 - print_circular_bug+0x28c/0x370 - check_noncircular+0x198/0x1ac - __lock_acquire+0x15a8/0x2084 - lock_acquire+0x1cc/0x350 - rt_spin_lock+0x50/0x1f0 - macb_start_xmit+0x808/0xb7c - dev_hard_start_xmit+0x94/0x284 - sch_direct_xmit+0x8c/0x37c - __dev_queue_xmit+0x708/0x1120 - neigh_resolve_output+0x148/0x28c - ip6_finish_output2+0x2c0/0xb2c - __ip6_finish_output+0x114/0x308 - ip6_output+0xc4/0x4a4 - mld_sendpack+0x220/0x68c - mld_ifc_work+0x2a8/0x4f4 - process_one_work+0x20c/0x5f8 - worker_thread+0x1b0/0x35c - kthread+0x144/0x200 - ret_from_fork+0x10/0x20 - -Notably, invoking the mog_init_rings() callback upon link establishment -is unnecessary. Instead, we can exclusively call mog_init_rings() within -the ndo_open() callback. This adjustment resolves the deadlock issue. -Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings() -when opening the network interface via at91ether_open(), moving -mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC -check. - -Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()") -Cc: stable@vger.kernel.org -Suggested-by: Kevin Hao -Signed-off-by: Xiaolei Wang -Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com -Signed-off-by: Paolo Abeni -Signed-off-by: Greg Kroah-Hartman ---- - drivers/net/ethernet/cadence/macb_main.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - ---- a/drivers/net/ethernet/cadence/macb_main.c -+++ b/drivers/net/ethernet/cadence/macb_main.c -@@ -777,7 +777,6 @@ static void macb_mac_link_up(struct phyl - /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down - * cleared the pipeline and control registers. - */ -- bp->macbgem_ops.mog_init_rings(bp); - macb_init_buffers(bp); - - for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) -@@ -2478,6 +2477,8 @@ static void gem_init_rings(struct macb * - unsigned int q; - int i; - -+ bp->macbgem_ops.mog_init_rings(bp); -+ - for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) { - for (i = 0; i < bp->tx_ring_size; i++) { - desc = macb_tx_desc(queue, i); diff --git a/queue-5.15/series b/queue-5.15/series index a2258ae4f4..4ca0398e6b 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -405,7 +405,6 @@ fjes-add-missing-iounmap-in-fjes_hw_init.patch nfsd-drop-the-client-reference-in-client_states_open.patch net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch -net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch