Linux CIFS filesystem development
 help / color / mirror / Atom feed
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

             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