From: netdev-bot+sashiko@kernel.org
To: lucien.xin@gmail.com
Cc: netdev@vger.kernel.org, quic@lists.linux.dev,
davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, horms@kernel.org, metze@samba.org,
mbuhl@openbsd.org, tfanelli@redhat.com, hepengtao@xiaomi.com,
dreibh@simula.no, linux-cifs@vger.kernel.org, pc@manguebit.org,
linkinjeon@kernel.org, tom@talpey.com,
kernel-tls-handshake@lists.linux.dev, chuck.lever@oracle.com,
jlayton@kernel.org, steved@redhat.com, hare@suse.de,
aahringo@redhat.com, dhowells@redhat.com, matttbe@kernel.org,
mail@johnericson.me, xiyou.wangcong@gmail.com,
alibuda@linux.alibaba.com, jbaron@akamai.com,
illiliti@protonmail.com, sd@queasysnail.net,
marcelo.leitner@gmail.com, daniel@haxx.se,
andrew.gospodarek@broadcom.com, mef@scarletmail.rutgers.edu,
paul@jakma.org
Subject: Re: [PATCH net-next v15 04/15] quic: provide family ops for address and protocol
Date: Tue, 15 Sep 2026 19:50:25 +0000 [thread overview]
Message-ID: <178950182544.22033.14354065225790738831@kernel.org> (raw)
In-Reply-To: <627ebfc68bf77c45ae511de694aed1a4f2d9aa87.1789393775.git.lucien.xin@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 0 · Low: 2
- [Low] The commit message describes this patch only as the introduction
of family helper code ("provide helpers for routing, skb transmit…
- [Low] Both new transmit debug messages format the unsigned skb->len
field with the signed %d conversion instead of %u:…
--
quic: provide family ops for address and protocol
This adds net/quic/family.{c,h} with IPv4/IPv6 helpers for routing, lower
transmit, address parsing and comparison, MTU info extraction and UDP
tunnel socket configuration. It also wires quic_inet_getname() and the
non-SOL_QUIC setsockopt/getsockopt paths into the new helpers.
> diff --git a/net/quic/Makefile b/net/quic/Makefile
[ ... ]
> diff --git a/net/quic/family.c b/net/quic/family.c
> new file mode 100644
> index 0000000000000..f61a8203b2e17
> --- /dev/null
> +++ b/net/quic/family.c
> @@ -0,0 +1,446 @@
[ ... ]
> +static void quic_v4_lower_xmit(struct sock *sk, struct sk_buff *skb,
> + struct flowi *fl)
> +{
> + struct quic_skb_cb *cb = QUIC_SKB_CB(skb);
> + struct flowi4 *fl4 = &fl->u.ip4;
> + u8 tos = inet_sk(sk)->tos, ttl;
> + struct dst_entry *dst;
> + __be16 df = 0;
> +
> + pr_debug("%s: skb: %p, len: %d, num: %lld, %pI4:%d -> %pI4:%d\n",
> + __func__, skb, skb->len, cb->number, &fl4->saddr,
> + ntohs(fl4->fl4_sport), &fl4->daddr, ntohs(fl4->fl4_dport));
[Severity: Low]
This isn't a bug, but should the length conversion be %u here? skb->len is
declared unsigned in struct sk_buff:
include/linux/skbuff.h:
unsigned int len,
data_len;
The same mismatch appears in quic_v6_lower_xmit() below.
[ ... ]
> +static void quic_v6_lower_xmit(struct sock *sk, struct sk_buff *skb,
> + struct flowi *fl)
> +{
> + struct quic_skb_cb *cb = QUIC_SKB_CB(skb);
> + u8 tc = inet6_sk(sk)->tclass, ttl;
> + struct flowi6 *fl6 = &fl->u.ip6;
> + struct dst_entry *dst;
> + __be32 label;
> +
> + pr_debug("%s: skb: %p, len: %d, num: %lld, %pI6c:%d -> %pI6c:%d\n",
> + __func__, skb, skb->len, cb->number, &fl6->saddr,
> + ntohs(fl6->fl6_sport), &fl6->daddr, ntohs(fl6->fl6_dport));
[ ... ]
> diff --git a/net/quic/protocol.c b/net/quic/protocol.c
> index a53a2b1218a63..c5cd6d609d06f 100644
> --- a/net/quic/protocol.c
> +++ b/net/quic/protocol.c
> @@ -47,7 +47,7 @@ static int quic_inet_listen(struct socket *sock, int backlog)
> static int quic_inet_getname(struct socket *sock, struct sockaddr *uaddr,
> int peer)
> {
> - return -EOPNOTSUPP;
> + return quic_get_sk_addr(sock, uaddr, peer);
> }
>
> static __poll_t quic_inet_poll(struct file *file, struct socket *sock,
> diff --git a/net/quic/socket.c b/net/quic/socket.c
> index c2841caca5dcc..1c97d95c61b2c 100644
> --- a/net/quic/socket.c
> +++ b/net/quic/socket.c
> @@ -121,7 +121,8 @@ static int quic_setsockopt(struct sock *sk, int level, int optname,
> sockptr_t optval, unsigned int optlen)
> {
> if (level != SOL_QUIC)
> - return -EOPNOTSUPP;
> + return quic_common_setsockopt(sk, level, optname, optval,
> + optlen);
>
> return quic_do_setsockopt(sk, optname, optval, optlen);
> }
> @@ -136,7 +137,8 @@ static int quic_getsockopt(struct sock *sk, int level, int optname,
> char __user *optval, int __user *optlen)
> {
> if (level != SOL_QUIC)
> - return -EOPNOTSUPP;
> + return quic_common_getsockopt(sk, level, optname, optval,
> + optlen);
>
> return quic_do_getsockopt(sk, optname, USER_SOCKPTR(optval),
> USER_SOCKPTR(optlen));
[Severity: Low]
Could the changelog mention these three behaviour changes? The commit
message describes the patch as
"The new quic_family.{c,h} provide helpers for routing, skb transmit
handling, address parsing and comparison and UDP socket config
initializing etc."
but beyond adding helpers, three entry points that previously returned
-EOPNOTSUPP now work:
quic_inet_getname() -> quic_get_sk_addr()
quic_setsockopt() -> quic_common_setsockopt() -> ip_setsockopt()/ipv6_setsockopt()
quic_getsockopt() -> quic_common_getsockopt() -> ip_getsockopt()/ipv6_getsockopt()
So getsockname()/getpeername() start returning addresses, and every
level != SOL_QUIC option is now passed through to the IP/IPv6 option
handlers. Some of those values are consumed by code added in this same
patch: inet_sk(sk)->tos in quic_v4_lower_xmit(), inet6_sk(sk)->tclass in
quic_v6_lower_xmit(), ipv6_only_sock() in quic_v6_udp_conf_init(), and
pmtudisc through ip_dont_fragment() and quic_sk_accept_pmtu().
Also, the message names the new files quic_family.{c,h} while the patch
adds net/quic/family.{c,h}.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1789393775.git.lucien.xin%40gmail.com
next reply other threads:[~2026-09-15 19:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 19:50 netdev-bot+sashiko [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-09-14 13:49 [PATCH net-next v15 00/15] net: introduce QUIC infrastructure and core subcomponents Xin Long
2026-09-14 13:49 ` [PATCH net-next v15 04/15] quic: provide family ops for address and protocol Xin Long
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=178950182544.22033.14354065225790738831@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=aahringo@redhat.com \
--cc=alibuda@linux.alibaba.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=chuck.lever@oracle.com \
--cc=daniel@haxx.se \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dreibh@simula.no \
--cc=edumazet@google.com \
--cc=hare@suse.de \
--cc=hepengtao@xiaomi.com \
--cc=horms@kernel.org \
--cc=illiliti@protonmail.com \
--cc=jbaron@akamai.com \
--cc=jlayton@kernel.org \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=mail@johnericson.me \
--cc=marcelo.leitner@gmail.com \
--cc=matttbe@kernel.org \
--cc=mbuhl@openbsd.org \
--cc=mef@scarletmail.rutgers.edu \
--cc=metze@samba.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@jakma.org \
--cc=pc@manguebit.org \
--cc=quic@lists.linux.dev \
--cc=sd@queasysnail.net \
--cc=steved@redhat.com \
--cc=tfanelli@redhat.com \
--cc=tom@talpey.com \
--cc=xiyou.wangcong@gmail.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