All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Ronald Wahl <rwahl@gmx.de>
Cc: Ronald Wahl <ronald.wahl@raritan.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3] net: ks8851: Fix deadlock with the SPI chip variant
Date: Mon, 8 Jul 2024 10:11:55 +0100	[thread overview]
Message-ID: <20240708091155.GI1481495@kernel.org> (raw)
In-Reply-To: <20240706101337.854474-1-rwahl@gmx.de>

On Sat, Jul 06, 2024 at 12:13:37PM +0200, Ronald Wahl wrote:
> From: Ronald Wahl <ronald.wahl@raritan.com>
> 
> 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@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Cc: netdev@vger.kernel.org
> Cc: stable@vger.kernel.org # 5.10+
> Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
> ---
> 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@kernel.org>


  reply	other threads:[~2024-07-08  9:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-06 10:13 [PATCH v3] net: ks8851: Fix deadlock with the SPI chip variant Ronald Wahl
2024-07-08  9:11 ` Simon Horman [this message]
2024-07-09 18:22 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240708091155.GI1481495@kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ronald.wahl@raritan.com \
    --cc=rwahl@gmx.de \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.