From: Qingfang Deng <qingfang.deng@linux.dev>
To: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Qingfang Deng <qingfang.deng@linux.dev>,
Guillaume Nault <gnault@redhat.com>,
Breno Leitao <leitao@debian.org>,
Taegu Ha <hataegu0826@gmail.com>, Kees Cook <kees@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-ppp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net-next] ppp: consolidate RX skb queueing
Date: Tue, 28 Apr 2026 10:44:23 +0800 [thread overview]
Message-ID: <20260428024426.48605-1-qingfang.deng@linux.dev> (raw)
In ppp_input() and ppp_receive_nonmp_frame(), received skbs are queued
for userspace delivery using the same open-coded pattern:
skb_queue_tail(&pf->rq, skb);
while (pf->rq.qlen > PPP_MAX_RQLEN &&
(skb = skb_dequeue(&pf->rq)))
kfree_skb(skb);
wake_up_interruptible(&pf->rwait);
This has a potential race: skb_queue_tail() releases the queue lock,
then qlen is read locklessly before skb_dequeue() re-acquires it.
Another CPU enqueueing concurrently could cause the length check to see
stale data. This race is benign, as it only causes extra skbs to be
freed in the worst case.
Introduce ppp_file_queue_rx_skb() to perform the enqueue, length check,
and trim atomically under a single pf->rq.lock critical section. As both
callers have softirq disabled, plain spin_lock() can be used instead of
_bh()/_irqsave() variants. Since only one skb is enqueued at a time, the
queue can exceed PPP_MAX_RQLEN by at most one frame, so replace the
while-loop with an if-statement. While at it, use skb_queue_len()
instead of open-coding the qlen access.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
drivers/net/ppp/ppp_generic.c | 37 ++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 57c68efa5ff8..6ab5011540a0 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -2307,6 +2307,27 @@ static bool ppp_channel_bridge_input(struct channel *pch, struct sk_buff *skb)
return !!pchb;
}
+/* Queue up and deliver a received skb to userspace.
+ * Must be called in softirq.
+ */
+static void ppp_file_queue_rx_skb(struct ppp_file *pf, struct sk_buff *skb)
+{
+ spin_lock(&pf->rq.lock);
+ __skb_queue_tail(&pf->rq, skb);
+ /* limit queue length by dropping old frames */
+ if (unlikely(skb_queue_len(&pf->rq) > PPP_MAX_RQLEN)) {
+ struct sk_buff *old = __skb_peek(&pf->rq);
+
+ __skb_unlink(old, &pf->rq);
+ spin_unlock(&pf->rq.lock);
+ kfree_skb(old);
+ } else {
+ spin_unlock(&pf->rq.lock);
+ }
+ /* wake up any process polling or blocking on read */
+ wake_up_interruptible(&pf->rwait);
+}
+
void
ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
{
@@ -2337,12 +2358,7 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
proto = PPP_PROTO(skb);
if (!ppp || proto >= 0xc000 || proto == PPP_CCPFRAG) {
/* put it on the channel queue */
- skb_queue_tail(&pch->file.rq, skb);
- /* drop old frames if queue too long */
- while (pch->file.rq.qlen > PPP_MAX_RQLEN &&
- (skb = skb_dequeue(&pch->file.rq)))
- kfree_skb(skb);
- wake_up_interruptible(&pch->file.rwait);
+ ppp_file_queue_rx_skb(&pch->file, skb);
} else {
ppp_do_recv(ppp, skb, pch);
}
@@ -2480,14 +2496,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
npi = proto_to_npindex(proto);
if (npi < 0) {
/* control or unknown frame - pass it to pppd */
- skb_queue_tail(&ppp->file.rq, skb);
- /* limit queue length by dropping old frames */
- while (ppp->file.rq.qlen > PPP_MAX_RQLEN &&
- (skb = skb_dequeue(&ppp->file.rq)))
- kfree_skb(skb);
- /* wake up any process polling or blocking on read */
- wake_up_interruptible(&ppp->file.rwait);
-
+ ppp_file_queue_rx_skb(&ppp->file, skb);
} else {
/* network protocol frame - give it to the kernel */
--
2.43.0
next reply other threads:[~2026-04-28 2:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 2:44 Qingfang Deng [this message]
2026-04-28 6:43 ` [PATCH net-next] ppp: consolidate RX skb queueing Sebastian Andrzej Siewior
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=20260428024426.48605-1-qingfang.deng@linux.dev \
--to=qingfang.deng@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gnault@redhat.com \
--cc=hataegu0826@gmail.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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