public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: lucien.xin@gmail.com
Cc: Simon Horman <horms@kernel.org>,
	steved@redhat.com, marcelo.leitner@gmail.com,
	aahringo@redhat.com, alibuda@linux.alibaba.com,
	jbaron@akamai.com, hare@suse.de, kuba@kernel.org, tom@talpey.com,
	linux-cifs@vger.kernel.org, daniel@haxx.se, quic@lists.linux.dev,
	jlayton@kernel.org, tfanelli@redhat.com, dhowells@redhat.com,
	linkinjeon@kernel.org, hepengtao@xiaomi.com, pc@manguebit.com,
	kernel-tls-handshake@lists.linux.dev, illiliti@protonmail.com,
	xiyou.wangcong@gmail.com, andrew.gospodarek@broadcom.com,
	mail@johnericson.me, edumazet@google.com, pabeni@redhat.com,
	matttbe@kernel.org, netdev@vger.kernel.org, smfrench@gmail.com,
	metze@samba.org, mbuhl@openbsd.org, chuck.lever@oracle.com,
	dreibh@simula.no, davem@davemloft.net, sd@queasysnail.net
Subject: Re: [net-next,v9,15/15] quic: add packet parser base
Date: Thu,  5 Feb 2026 11:55:42 +0000	[thread overview]
Message-ID: <20260205115542.2195362-1-horms@kernel.org> (raw)
In-Reply-To: <431335747d3604c46f2e57a32d839a73aa8a8536.1770042461.git.lucien.xin@gmail.com>

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 packet parser base

This patch uses 'quic_packet' to handle packing of QUIC packets on the
receive (RX) path. It introduces mechanisms to parse the ALPN from client
Initial packets to determine the correct listener socket, routes received
packets accordingly, and adds support for ICMP-based MTU updates by
locating the relevant socket and updating the stored PMTU.

> diff --git a/net/quic/packet.c b/net/quic/packet.c
> index cf64a6aaa795..16a7db6ccd87 100644
> --- a/net/quic/packet.c
> +++ b/net/quic/packet.c

[ ... ]

> @@ -14,6 +14,637 @@
>
>  #define QUIC_HLEN		1
>
> +/* Handle ICMP Toobig packet and update QUIC socket path MTU. */
> +static int quic_packet_rcv_err(struct sock *sk, struct sk_buff *skb)
> +{
> +	union quic_addr daddr, saddr;
> +	u32 info;
> +
> +	/* All we can do is lookup the matching QUIC socket by addresses. */
> +	quic_get_msg_addrs(skb, &saddr, &daddr);
> +	sk = quic_sock_lookup(skb, &daddr, &saddr, sk, NULL);

Are the address arguments swapped in quic_packet_rcv_err()? Looking at
other call sites in this file, quic_get_msg_addrs is consistently called
with &daddr first, then &saddr:

  Line 476 in quic_packet_get_listen_sock():
    quic_get_msg_addrs(skb, &daddr, &saddr);

  Line 513 in quic_packet_get_sock():
    quic_get_msg_addrs(skb, &daddr, &saddr);

  Line 536 in quic_packet_get_sock():
    quic_get_msg_addrs(skb, &daddr, &saddr);

But here quic_packet_rcv_err() passes &saddr first, then &daddr.

Looking at the implementation of quic_v4_get_msg_addrs() in
net/quic/family.c, the function extracts addresses from the packet as:

  sa->v4.sin_port = uh->source;
  sa->v4.sin_addr.s_addr = ip_hdr(skb)->saddr;
  da->v4.sin_port = uh->dest;
  da->v4.sin_addr.s_addr = ip_hdr(skb)->daddr;

So sa gets the packet's source address (remote), and da gets the packet's
destination address (local).

Then quic_sock_lookup() in net/quic/socket.c expects:

  if (quic_cmp_sk_addr(tmp, quic_path_saddr(paths, 0), sa) &&
      quic_cmp_sk_addr(tmp, quic_path_daddr(paths, 0), da) &&

This compares the socket's local address with sa and the socket's remote
address with da, meaning sa should be the local (packet dest) address and
da should be the remote (packet source) address.

With the swapped arguments, quic_packet_rcv_err() would pass the remote
address where the local is expected and vice versa, causing the socket
lookup to fail. This would prevent ICMP Packet Too Big messages from being
processed correctly, breaking Path MTU Discovery.

> +	if (!sk)
> +		return -ENOENT;
> +
> +	if (quic_get_mtu_info(skb, &info)) {
> +		sock_put(sk);
> +		return 0;
> +	}
> +
> +	/* Success: update socket path MTU info. */
> +	bh_lock_sock(sk);
> +	quic_paths(sk)->mtu_info = info;

[ ... ]

  reply	other threads:[~2026-02-05 11:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02 14:27 [PATCH net-next v9 00/15] net: introduce QUIC infrastructure and core subcomponents Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 01/15] net: define IPPROTO_QUIC and SOL_QUIC constants Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 02/15] net: build socket infrastructure for QUIC protocol Xin Long
2026-02-05 11:54   ` [net-next,v9,02/15] " Simon Horman
2026-02-05 12:48     ` Paolo Abeni
2026-02-05 19:03       ` Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 03/15] quic: provide common utilities and data structures Xin Long
2026-02-05 11:54   ` [net-next,v9,03/15] " Simon Horman
2026-02-05 12:51     ` Paolo Abeni
2026-02-05 19:18       ` Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 04/15] quic: provide family ops for address and protocol Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 05/15] quic: provide quic.h header files for kernel and userspace Xin Long
2026-02-05 11:55   ` [net-next,v9,05/15] " Simon Horman
2026-02-05 19:37     ` Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 06/15] quic: add stream management Xin Long
2026-02-05 11:55   ` [net-next,v9,06/15] " Simon Horman
2026-02-05 18:56     ` Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 07/15] quic: add connection id management Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 08/15] quic: add path management Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 09/15] quic: add congestion control Xin Long
2026-02-05 11:55   ` [net-next,v9,09/15] " Simon Horman
2026-02-05 19:00     ` Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 10/15] quic: add packet number space Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 11/15] quic: add crypto key derivation and installation Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 12/15] quic: add crypto packet encryption and decryption Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 13/15] quic: add timer management Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 14/15] quic: add packet builder base Xin Long
2026-02-02 14:27 ` [PATCH net-next v9 15/15] quic: add packet parser base Xin Long
2026-02-05 11:55   ` Simon Horman [this message]
2026-02-05 19:02     ` [net-next,v9,15/15] " 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=20260205115542.2195362-1-horms@kernel.org \
    --to=horms@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=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=metze@samba.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pc@manguebit.com \
    --cc=quic@lists.linux.dev \
    --cc=sd@queasysnail.net \
    --cc=smfrench@gmail.com \
    --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