From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SSo2JKdh; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id A76D85A061E for ; Thu, 13 Nov 2025 07:33:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763015622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1x3fw8NgB/PJphzsHS5eucby7ahHEczUa4l6qZYjgY=; b=SSo2JKdh4d+nQyTqeg0wkTwZGJprEw4RlQmdyfYR+tDjlpDWHXNyrl8KANK3oX7W4gxL7y 9qmcUx65EgUxxYWuNp9nrkZKDjg1tZsDgGbWh3mBir3T18JLh65/C9xWBNqeI6vhSfx4VQ Ekgz2gnKmQS143TJTrD4ASS6ESH3nZ0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-691-EmZrm8INMUCEeOS6pyhWTQ-1; Thu, 13 Nov 2025 01:33:40 -0500 X-MC-Unique: EmZrm8INMUCEeOS6pyhWTQ-1 X-Mimecast-MFC-AGG-ID: EmZrm8INMUCEeOS6pyhWTQ_1763015619 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-429cdb0706aso560655f8f.0 for ; Wed, 12 Nov 2025 22:33:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763015618; x=1763620418; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C1x3fw8NgB/PJphzsHS5eucby7ahHEczUa4l6qZYjgY=; b=U6RO3DURa/aPFOKeYnPn/asa0dcvuWSbi0T3Q3xItWUo9ZNZluKyKaKv89+rrGQQ/T mTvaBuz/i4I7WWRntlThi0SNuFFkgLE9EM9Y6/GJyHLhxsewtOwTCH2OBnx/+obIsM9l 2hhtDKtgfKpJjcZdxFvDA5uvuXE5J6giO9c1CnLsdnQJjPL2QtSgWlauRIwkJpv/rORE yxsYUqrA+pPXsAZdZnNb5tSTNwbDiEhWiSHSi4Si5ZG+dU+lHTlvwDtCVwdh7ReNqLoP SPVcDhixYqYcJrHv3JZRCPAemGX17OxVZm73ULopbVknG/UseQNErRMeSFHx1Eio0cdb LlqA== X-Gm-Message-State: AOJu0YyVxnVrmt4jytszSvrGen+4OL2h6IWgmpPS+cgNEmq2w8Yg1bYK ZBuqbVT3rp8YDC0BwHrDikQ6nAJARHXIxrOI95FR+3w577+jr6/i54ryqfsc5CzPRKvInSXVkj4 Y0YHsGbqLXET0bkES3izMw9H6nzTV1lUNYdZvuSOsAYxJFcaLgmu+G3N+I1DIMA== X-Gm-Gg: ASbGnct+Mzyj6FHo/sV2B7wyIaodZqmUrqD94w+0Zqts71TUduzwaqXtWVEm88+mB7K a3vw/nMRw5H5VQX+tClXlmjW405mWksdlzC37Ao54mSjdN5dlvMX7f4gBsCKK7IyjCN3BWTUejl xKi21dFRjx3N9UeR7km4w1SuAA78xmUxzR/e1mj5FjbMYxigHQT21tvSBER97CiJXrI8AIqxVe9 dYyNpBELkNA7rpnZMASrvP1NqBvxQoO/dc/eRGsQNqlZX3t8GWP0drHS66y97XClN9aomk9BvDz 5tbVVvWK3oXrX4cWvgDYuLoLye4qOu1SHRCmISmX7VmqZVRPd40kSwffuvqb69AXZAy2gITx0/R n4Jh8GJ+nsepXVgxVENoxcPaEj7M= X-Received: by 2002:a05:6000:651:b0:400:7e60:7ee0 with SMTP id ffacd0b85a97d-42b4baecb4dmr4435889f8f.0.1763015618404; Wed, 12 Nov 2025 22:33:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IEf3A71g1gRfEBpMIh0xDDCu7Yqx7rP7BMkxuR23qvvD/QeqVrx4L9ci+WKMRcBLY2uJas7QQ== X-Received: by 2002:a05:6000:651:b0:400:7e60:7ee0 with SMTP id ffacd0b85a97d-42b4baecb4dmr4435867f8f.0.1763015617884; Wed, 12 Nov 2025 22:33:37 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42b53dea1c9sm1944831f8f.0.2025.11.12.22.33.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Nov 2025 22:33:36 -0800 (PST) Date: Thu, 13 Nov 2025 07:33:35 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 6/8] util: Fix setting of IPV6_V6ONLY socket option Message-ID: <20251113073335.3a73f9b9@elisabeth> In-Reply-To: <20251029062628.1647051-7-david@gibson.dropbear.id.au> References: <20251029062628.1647051-1-david@gibson.dropbear.id.au> <20251029062628.1647051-7-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: dplDh8bJU0p_LqgT-_8h4uPoGJsimufKNz0JliLlPyY_1763015619 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: YEKVGBBLBJUISFJMJZX3MMUGYLMBQ6QT X-Message-ID-Hash: YEKVGBBLBJUISFJMJZX3MMUGYLMBQ6QT X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 29 Oct 2025 17:26:26 +1100 David Gibson wrote: > Currently we only call setsockopt() on IPV6_V6ONLY when we want to set it > to 1, which we typically do on all IPv6 sockets except those explicitly for > dual stack listening. That's not quite right in two ways: > > * Although IPV6_V6ONLY==0 is normally the default on Linux, that can be > changed with the net.ipv6.bindv6only sysctl. It may also have different > defaults on other OSes if we ever support them. We know we need it off > for dual stack sockets, so explicitly set it to 0 in that case. > > * At the same time setting IPV6_V6ONLY to 1 for IPv6 sockets bound to a > specific address is harmless but pointless. Don't set the option at all > in this case, saving a syscall. I haven't checked the implications of this but __inet6_bind() handles address "types" IPV6_ADDR_ANY and IPV6_ADDR_MAPPED in the same way, for IPV6_V6ONLY purposes. I'm not sure if this has any influence on functionality though. > > Signed-off-by: David Gibson > --- > util.c | 27 +++++++++++++++++++++------ > 1 file changed, 21 insertions(+), 6 deletions(-) > > diff --git a/util.c b/util.c > index c94efae4..62f43895 100644 > --- a/util.c > +++ b/util.c > @@ -45,14 +45,14 @@ > * @type: epoll type > * @sa: Socket address to bind to > * @ifname: Interface for binding, NULL for any > - * @v6only: Set IPV6_V6ONLY socket option > + * @v6only: If >= 0, set IPV6_V6ONLY socket option to this value > * @data: epoll reference portion for protocol handlers > * > * Return: newly created socket, negative error code on failure > */ > static int sock_l4_(const struct ctx *c, enum epoll_type type, > const union sockaddr_inany *sa, const char *ifname, > - bool v6only, uint32_t data) > + int v6only, uint32_t data) > { > sa_family_t af = sa->sa_family; > union epoll_ref ref = { .type = type, .data = data }; > @@ -101,9 +101,11 @@ static int sock_l4_(const struct ctx *c, enum epoll_type type, > > ref.fd = fd; > > - if (v6only) > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &y, sizeof(y))) > - debug("Failed to set IPV6_V6ONLY on socket %i", fd); > + if (v6only >= 0) > + if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, > + &v6only, sizeof(v6only))) > + debug("Failed to set IPV6_V6ONLY to %d on socket %i", > + v6only, fd); Nit: curly brackets (two pairs) for consistency. > > if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &y, sizeof(y))) > debug("Failed to set SO_REUSEADDR on socket %i", fd); > @@ -186,7 +188,16 @@ int sock_l4(const struct ctx *c, enum epoll_type type, > const union sockaddr_inany *sa, const char *ifname, > uint32_t data) > { > - return sock_l4_(c, type, sa, ifname, sa->sa_family == AF_INET6, data); > + int v6only = -1; > + > + /* The option doesn't exist for IPv4 sockets, and is irrelevant for IPv6 > + * sockets with a non-wildcard address. Same as above: I don't think this is true, strictly speaking, but I didn't check whether this inaccuracy is in any way relevant. > + */ > + if (sa->sa_family == AF_INET6 && > + IN6_IS_ADDR_UNSPECIFIED(&sa->sa6.sin6_addr)) > + v6only = 1; > + > + return sock_l4_(c, type, sa, ifname, v6only, data); > } > > int sock_l4_dualstack(const struct ctx *c, enum epoll_type type, > @@ -198,6 +209,10 @@ int sock_l4_dualstack(const struct ctx *c, enum epoll_type type, > .sa6.sin6_port = htons(port), > }; > > + /* Dual stack sockets require IPV6_V6ONLY == 0. Usually that's the > + * default, but sysctl net.ipv6.bindv6only can change that, so set the > + * sockopt explicitly. > + */ > return sock_l4_(c, type, &sa, ifname, 0, data); > } > The rest of the series looks good to me, including 8/8, but it's not clear to me what the "secondary reasons" to consider 8/8 at this stage might be, so I'm not actually sure what to do with it. Is it because it drops some code? -- Stefano