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 for Android: free password hash cracker in your pocket

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

Message-ID: <CADvbK_cMDaSXcDC-iR_5dqPaz4O8o0mzYvNC+akQJyMzXnGq5Q@mail.gmail.com>
Date: Sat, 23 Aug 2025 13:22:50 -0400
From: Xin Long <lucien.xin@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: network dev <netdev@...r.kernel.org>, 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 Thu, Aug 21, 2025 at 9:17 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> 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.
I'm completely fine to change things to be like:

int quic_flow_route(struct sock *sk, union quic_addr *da, union
quic_addr *sa, struct flowi *fl)
{
        return da->sa.sa_family == AF_INET ? quic_v4_flow_route(sk,
da, sa, fl) :
                quic_v6_flow_route(sk, da, sa, fl);
}

>
> [...]
> > +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.
>
Right, I will add a helper.

Thanks.