Re: [PATCH net-next v2 02/15] net: build socket infrastructure for QUIC protocol
flat view
From: Paolo Abeni <pabeni@redhat.com>
Date: 2025-08-21 11:17:53
Also in:
linux-cifs
On 8/18/25 4:04 PM, Xin Long wrote:
quoted hunk ↗ jump to hunk
diff --git a/net/Makefile b/net/Makefile index aac960c41db6..7c6de28e9aa5 100644 --- a/net/Makefile +++ b/net/Makefile@@ -42,6 +42,7 @@ obj-$(CONFIG_PHONET) += phonet/ ifneq ($(CONFIG_VLAN_8021Q),) obj-y += 8021q/ endif +obj-$(CONFIG_IP_QUIC) += quic/ obj-$(CONFIG_IP_SCTP) += sctp/ obj-$(CONFIG_RDS) += rds/ obj-$(CONFIG_WIRELESS) += wireless/diff --git a/net/quic/Kconfig b/net/quic/Kconfig new file mode 100644 index 000000000000..b64fa398750e --- /dev/null +++ b/net/quic/Kconfig@@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +# +# QUIC configuration +# + +menuconfig IP_QUIC + tristate "QUIC: A UDP-Based Multiplexed and Secure Transport (Experimental)" + depends on INET + depends on IPV6
What if IPV6=m ?
quoted hunk ↗ jump to hunk
+ select CRYPTO + select CRYPTO_HMAC + select CRYPTO_HKDF + select CRYPTO_AES + select CRYPTO_GCM + select CRYPTO_CCM + select CRYPTO_CHACHA20POLY1305 + select NET_UDP_TUNNEL
Possibly: default n ? [...]
quoted hunk ↗ jump to hunk
+static int quic_init_sock(struct sock *sk) +{ + sk->sk_destruct = inet_sock_destruct; + sk->sk_write_space = quic_write_space; + sock_set_flag(sk, SOCK_USE_WRITE_QUEUE); + + WRITE_ONCE(sk->sk_sndbuf, READ_ONCE(sysctl_quic_wmem[1])); + WRITE_ONCE(sk->sk_rcvbuf, READ_ONCE(sysctl_quic_rmem[1])); + + local_bh_disable();
Why?
quoted hunk ↗ jump to hunk
+ sk_sockets_allocated_inc(sk); + sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1); + local_bh_enable(); + + return 0; +} + +static void quic_destroy_sock(struct sock *sk) +{ + local_bh_disable();
Same question :) [...]
quoted hunk ↗ jump to hunk
+static int quic_disconnect(struct sock *sk, int flags) +{ + quic_set_state(sk, QUIC_SS_CLOSED); /* for a listen socket only */ + return 0; +}
disconnect() primary use-case is creating a lot of syzkaller reports. Since there should be no legacy/backward compatibility issue, I suggest considering a simple implementation always failing. /P