Re: [net-next,v9,06/15] quic: add stream management
From: Simon Horman <horms@kernel.org>
Date: 2026-02-05 11:55:32
Also in:
linux-cifs
This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- quic: add stream management This patch introduces stream management infrastructure for the QUIC protocol, including a hash table for tracking active streams, functions for acquiring and releasing streams, and logic for detecting stream ID limits.
quoted hunk ↗ jump to hunk
diff --git a/net/quic/socket.c b/net/quic/socket.c index b86989080184..d6f25669c693 100644 --- a/net/quic/socket.c +++ b/net/quic/socket.c@@ -41,6 +41,9 @@ static int quic_init_sock(struct sock *sk) sk->sk_write_space = quic_write_space; sock_set_flag(sk, SOCK_USE_WRITE_QUEUE); + if (quic_stream_init(quic_streams(sk))) + return -ENOMEM;
If quic_stream_init() fails here, the function returns before calling
sk_sockets_allocated_inc() and sock_prot_inuse_add() below. However,
when initialization fails, inet_create() calls sk_common_release() which
invokes quic_destroy_sock():
quic_init_sock()
quic_stream_init() fails
return -ENOMEM
-> sk_common_release()
-> quic_destroy_sock()
-> sk_sockets_allocated_dec() // underflow
-> sock_prot_inuse_add(..., -1) // underflow
Can this cause counter underflow since the increments never executed but
the decrements in quic_destroy_sock() are unconditional?
quoted hunk ↗ jump to hunk
+ WRITE_ONCE(sk->sk_sndbuf, READ_ONCE(sysctl_quic_wmem[1])); WRITE_ONCE(sk->sk_rcvbuf, READ_ONCE(sysctl_quic_rmem[1]));@@ -52,6 +55,8 @@ static int quic_init_sock(struct sock *sk) static void quic_destroy_sock(struct sock *sk) { + quic_stream_free(quic_streams(sk)); + quic_data_free(quic_ticket(sk));
[ ... ]