On Sat, Jul 06, 2024 at 12:13:37PM +0200, Ronald Wahl wrote:
> From: Ronald Wahl <ronald.wahl@xxxxxxxxxxx>
>
> When SMP is enabled and spinlocks are actually functional then there is
> a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi
> and ks8851_irq:
>
> watchdog: BUG: soft lockup - CPU#0 stuck for 27s!
> call trace:
> queued_spin_lock_slowpath+0x100/0x284
> do_raw_spin_lock+0x34/0x44
> ks8851_start_xmit_spi+0x30/0xb8
> ks8851_start_xmit+0x14/0x20
> netdev_start_xmit+0x40/0x6c
> dev_hard_start_xmit+0x6c/0xbc
> sch_direct_xmit+0xa4/0x22c
> __qdisc_run+0x138/0x3fc
> qdisc_run+0x24/0x3c
> net_tx_action+0xf8/0x130
> handle_softirqs+0x1ac/0x1f0
> __do_softirq+0x14/0x20
> ____do_softirq+0x10/0x1c
> call_on_irq_stack+0x3c/0x58
> do_softirq_own_stack+0x1c/0x28
> __irq_exit_rcu+0x54/0x9c
> irq_exit_rcu+0x10/0x1c
> el1_interrupt+0x38/0x50
> el1h_64_irq_handler+0x18/0x24
> el1h_64_irq+0x64/0x68
> __netif_schedule+0x6c/0x80
> netif_tx_wake_queue+0x38/0x48
> ks8851_irq+0xb8/0x2c8
> irq_thread_fn+0x2c/0x74
> irq_thread+0x10c/0x1b0
> kthread+0xc8/0xd8
> ret_from_fork+0x10/0x20
>
> This issue has not been identified earlier because tests were done on
> a device with SMP disabled and so spinlocks were actually NOPs.
>
> Now use spin_(un)lock_bh for TX queue related locking to avoid execution
> of softirq work synchronously that would lead to a deadlock.
>
> Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>
> Cc: Jakub Kicinski <kuba@xxxxxxxxxx>
> Cc: Paolo Abeni <pabeni@xxxxxxxxxx>
> Cc: Simon Horman <horms@xxxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx
> Cc: stable@xxxxxxxxxxxxxxx # 5.10+
> Signed-off-by: Ronald Wahl <ronald.wahl@xxxxxxxxxxx>
> ---
> V2: - use spin_lock_bh instead of moving netif_wake_queue outside of
> locked region (doing the same in the start_xmit function)
> - add missing net: tag
>
> V3: - spin_lock_bh(ks->statelock) always except in xmit which is in BH
> already
I agree that this lock is now always either taken _bh,
or in the xmit path which is executed in BH context.
Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
