netdev - Re: [PATCH net-next v2 04/15] quic: provide family ops for address and protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7cfc62a6-b988-400d-829a-306211e1a156@redhat.com>
Date: Thu, 21 Aug 2025 15:17:36 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Xin Long <lucien.xin@...il.com>, network dev <netdev@...r.kernel.org>
Cc: davem@...emloft.net, kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>,
 Simon Horman <horms@...nel.org>, Stefan Metzmacher <metze@...ba.org>,
 Moritz Buhl <mbuhl@...nbsd.org>, Tyler Fanelli <tfanelli@...hat.com>,
 Pengtao He <hepengtao@...omi.com>, linux-cifs@...r.kernel.org,
 Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>,
 Paulo Alcantara <pc@...guebit.com>, Tom Talpey <tom@...pey.com>,
 kernel-tls-handshake@...ts.linux.dev, Chuck Lever <chuck.lever@...cle.com>,
 Jeff Layton <jlayton@...nel.org>, Benjamin Coddington <bcodding@...hat.com>,
 Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>,
 Alexander Aring <aahringo@...hat.com>, David Howells <dhowells@...hat.com>,
 Cong Wang <xiyou.wangcong@...il.com>, "D . Wythe"
 <alibuda@...ux.alibaba.com>, Jason Baron <jbaron@...mai.com>,
 illiliti <illiliti@...tonmail.com>, Sabrina Dubroca <sd@...asysnail.net>,
 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
 Daniel Stenberg <daniel@...x.se>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 04/15] quic: provide family ops for address
 and protocol

On 8/18/25 4:04 PM, Xin Long wrote:
> This patch introduces two new abstraction structures to simplify handling
> of IPv4 and IPv6 differences across the QUIC stack:
> 
> - quic_addr_family_ops: for address comparison, flow routing,
>   UDP config, MTU lookup, formatted output, etc.
> 
> - quic_proto_family_ops: for socket address helpers and preference.
> 
> With these additions, the QUIC core logic can remain agnostic of the
> address family and socket type, improving modularity and reducing
> repetitive checks throughout the codebase.

Given that you wrap the ops call in quick_<op>() helper, I'm wondering
if such abstraction is necessary/useful? 'if' statements in the quick
helper will likely reduce the code size, and will the indirect function
call overhead.

[...]
> +static void quic_v6_set_sk_addr(struct sock *sk, union quic_addr *a, bool src)
> +{
> +	if (src) {
> +		inet_sk(sk)->inet_sport = a->v4.sin_port;
> +		if (a->sa.sa_family == AF_INET) {
> +			sk->sk_v6_rcv_saddr.s6_addr32[0] = 0;
> +			sk->sk_v6_rcv_saddr.s6_addr32[1] = 0;
> +			sk->sk_v6_rcv_saddr.s6_addr32[2] = htonl(0x0000ffff);
> +			sk->sk_v6_rcv_saddr.s6_addr32[3] = a->v4.sin_addr.s_addr;
> +		} else {
> +			sk->sk_v6_rcv_saddr = a->v6.sin6_addr;
> +		}
> +	} else {
> +		inet_sk(sk)->inet_dport = a->v4.sin_port;
> +		if (a->sa.sa_family == AF_INET) {
> +			sk->sk_v6_daddr.s6_addr32[0] = 0;
> +			sk->sk_v6_daddr.s6_addr32[1] = 0;
> +			sk->sk_v6_daddr.s6_addr32[2] = htonl(0x0000ffff);
> +			sk->sk_v6_daddr.s6_addr32[3] = a->v4.sin_addr.s_addr;
> +		} else {
> +			sk->sk_v6_daddr = a->v6.sin6_addr;
> +		}
> +	}

You could factor the addr assignment in an helper and avoid some code
duplication.

/P