From: sashiko-bot@kernel.org
To: "Karl Mehltretter" <kmehltretter@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH net 2/2] netpoll: avoid blocking on the transmit lock in queue_process
Date: Tue, 29 Sep 2026 06:43:06 +0000 [thread overview]
Message-ID: <20260929064307.569CE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928064239.32456-3-kmehltretter@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: severe latency in netpoll queue_process on lock contention
--
commit eadeea48c72992b0b24239d8a823d8f836b84527
Author: Karl Mehltretter <kmehltretter@gmail.com>
netpoll: avoid blocking on the transmit lock in queue_process
This commit replaces HARD_TX_LOCK() with HARD_TX_TRYLOCK() in queue_process()
to fix a sleeping-in-atomic bug on PREEMPT_RT. If the lock is held, it requeues
the skb and schedules a delayed work retry after HZ / 10.
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index e0cfcb05468e2..a3c94f0b3f764 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -166,7 +166,13 @@ static void queue_process(struct work_struct *work)
> skb_set_queue_mapping(skb, q_index);
> }
> txq = netdev_get_tx_queue(dev, q_index);
> - HARD_TX_LOCK(dev, txq, smp_processor_id());
> + if (!HARD_TX_TRYLOCK(dev, txq)) {
> + netpoll_txq_queue_head(npinfo, skb);
> + local_irq_restore(flags);
> +
> + schedule_delayed_work(&npinfo->tx_work, HZ / 10);
> + return;
[Severity: High]
Does this schedule an excessively long delay when encountering a transient
spinlock contention?
When queue_process() attempts to transmit a deferred skb, it uses
HARD_TX_TRYLOCK(). If another CPU is actively transmitting on the same queue,
the TX lock is transiently held and the trylock fails.
The TX spinlock is typically held for just a few microseconds during normal
network operations, but this introduces a 100ms (HZ / 10) delay upon lock
contention. Will this cause netpoll to stall for 100ms every time it
encounters a busy TX lock, dropping throughput drastically (e.g., to ~10
pkts/sec) and likely causing the deferred queue to overflow resulting in
lost kernel logs?
> + }
> if (netif_xmit_frozen_or_stopped(txq) ||
> !dev_xmit_complete(netpoll_start_xmit(skb, dev, txq))) {
> netpoll_txq_queue_head(npinfo, skb);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928064239.32456-1-kmehltretter@gmail.com?part=2
prev parent reply other threads:[~2026-09-29 6:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 6:42 [PATCH net 0/2] netpoll: fix PREEMPT_RT deferred transmit locking Karl Mehltretter
2026-09-28 6:42 ` [PATCH net 1/2] netpoll: use a raw lock for the deferred transmit queue Karl Mehltretter
2026-09-28 6:42 ` [PATCH net 2/2] netpoll: avoid blocking on the transmit lock in queue_process Karl Mehltretter
2026-09-29 6:43 ` sashiko-bot [this message]
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=20260929064307.569CE1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kmehltretter@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®