Re: [PATCH RFC net 1/2] datagram: Rehash sockets only if local address changed for their family

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 15 Nov 2024 19:23:42 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:

> > On Fri, 15 Nov 2024 12:48:29 -0500
> > Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> >   
> > > Stefano Brivio wrote:    
> > >
> > > [...]
> > >
> > > > diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
> > > > index cc6d0bd7b0a9..d52333e921f3 100644
> > > > --- a/net/ipv4/datagram.c
> > > > +++ b/net/ipv4/datagram.c
> > > > @@ -65,7 +65,7 @@ int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len
> > > >  		inet->inet_saddr = fl4->saddr;	/* Update source address */
> > > >  	if (!inet->inet_rcv_saddr) {
> > > >  		inet->inet_rcv_saddr = fl4->saddr;
> > > > -		if (sk->sk_prot->rehash)
> > > > +		if (sk->sk_prot->rehash && sk->sk_family == AF_INET)
> > > >  			sk->sk_prot->rehash(sk);      
> > > 
> > > When is sk_family != AF_INET in __ip4_datagram_connect?    

So, this is the only "mismatching" case (by design) I can actually
reproduce. Long story short:

int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr,
			   int addr_len)
{

	[...]

	if (usin->sin6_family == AF_INET) {
		if (ipv6_only_sock(sk))
			return -EAFNOSUPPORT;
		err = __ip4_datagram_connect(sk, uaddr, addr_len);

		[...]

here we (intentionally) call __ip4_datagram_connect() on an AF_INET6
socket because we're connecting a dual-stack socket to an IPv4 address.

This happens for me with sshd (from OpenSSH) doing getaddrinfo() at
boot, it's some DNS stuff, but I didn't trace it all the way. You can
also reproduce it with:

  socat UDP6-LISTEN:1337,null-eof STDOUT & { sleep 1; : | socat STDIN UDP4:0:1337,shut-null; }

All in all, I would keep those checks. Even if this is the only case
we currently see, the assumptions __ip4_datagram_connect() <-> AF_INET
and __ip6_datagram_connect() <-> AF_INET6 don't hold in general.

Or do you find them exceedingly verbose / harmful for any other reason?

I would also make it clearer in the commit message why we need them
in the next patch (once net-next reopens).

-- 
Stefano