From nobody Tue Feb 3 19:24:10 2026 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f5D1q0DPKz6QbnP; Tue, 03 Feb 2026 19:24:15 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f5D1p6lCkz3f8y; Tue, 03 Feb 2026 19:24:14 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770146654; 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=KT9Sp7zaBzdbFI9Fdf0I8xaUS712tXwY4c26Soxziww=; b=ZgiyexSogaOMb9nd6oMwVeH9nOiEsERsJlwkMrA5diBDZzpY922Jjy17BkPi37j/dNRfP6 vQhsHmYdLvZq3aieGablHYB6KZu0PGn332m7AAsyzEWkLLRR4oCpw+QAIUmkWKzqQhdCP5 ltbPEsMAWSV5cdQWm8x0EbgqloT1MKtoD5SN9F/LP8EkZbkyLfKmtv9XzfuKDya3NLibaz D5MD3ImxUzIrbpPrW8WOCIbWomhrwR0JkPgZ9RpsY2tlhf/4TyVSvaX09FvDPBvng4Wf9M dN322Imq2Q47CpTLb7B1G/6Ww/MJlhpgxD+z6DEegpMKroyNPhu6gcU3vXTWug== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770146654; a=rsa-sha256; cv=none; b=TB2oLKbluaZ1dyWr/eqcxWsfUhqRL3Y0Ti9UtKdkEVTnEEg7+F3q2Z2FdDLv37b1IDdhU1 2tW23UC6NMKjrHg0FxGErmDkE72par8UCThQHXdN9w60q9ygEaeU4KP0Vw+7Jg8Q2hs6iv JDMW8vf07+WrIHH0wn/XGFygND3JoLinKSgY05tZZATfrpATa4sHeyshfuY7xkMOh69q8U w4fMHdIS2aI8ViZmBvchgIt4ELXVVQ8BOuvBDL0E7bL6U0ovulyuX9IQF3Wc8LMpAl6cwD G+AM5urq8kXmvf6Ch96bJicHv+PS23rquRpIYQe09XTwqtGpoduS1ZEkeCLiMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770146654; 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=KT9Sp7zaBzdbFI9Fdf0I8xaUS712tXwY4c26Soxziww=; b=KoPZvDEVX4DBC7gcA5d+1xYNfKhV3uHlAhj3nhSSg9+Bj+ncg1nqLTv5VtgOCX2QJSpUpC nc+gE0Eo9wB2PSZnv5LsmblPC92f2C3u2N8cUr+nd5P5bMNtGEAGlt5AtZeui/eX9e0gzq KsT9w0+YRz9020Z0w8J5ynVzXI0JdcOpMYqIKUYK8MlccTikfqdsav/ROV+MsPShz3uMD0 MW8doAd2Qv1hwqh04A6LPBaIXsMzhU2eZPxjkdLbieqi19ZD1WMN2d6SQsPCca/Zpgjylv xKBq2ldFUdDxj1S0juAOY7SzXWIBZ54nuFuyp+r5AiVmMn2LyrZPePEpbN0HAQ== Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:397f:c722:123e:f103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f5D1p0fKgz4L9; Tue, 03 Feb 2026 19:24:13 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: git: d195b3783fa4 - main - sctp: fix socket type created by sctp_peeloff() From: Michael Tuexen In-Reply-To: Date: Tue, 3 Feb 2026 20:24:10 +0100 Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <697e46e9.2271d.66b41ecf@gitrepo.freebsd.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3864.300.41.1.7) > On 2. Feb 2026, at 20:28, Gleb Smirnoff wrote: >=20 > Michael, >=20 > On Sat, Jan 31, 2026 at 06:16:09PM +0000, Michael Tuexen wrote: > M> commit d195b3783fa4de5c1a95f6d95eb9444abce6778b > M> Author: Michael Tuexen > M> AuthorDate: 2026-01-31 18:11:08 +0000 > M> Commit: Michael Tuexen > M> CommitDate: 2026-01-31 18:11:08 +0000 > M>=20 > M> sctp: fix socket type created by sctp_peeloff() > M> =20 > M> When calling sctp_peeloff() on a SOCK_SEQPACKET socket, the = created > M> and returned socket has the type SOCK_STREAM. > M> This is specified in section 9.2 of RFC 6458. > M> =20 > M> Reported by: Xin Long > M> MFC after: 3 days > M> --- > M> sys/kern/uipc_socket.c | 6 ++++-- > M> 1 file changed, 4 insertions(+), 2 deletions(-) > M>=20 > M> diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c > M> index efc8ebfcece2..4014006ce2e5 100644 > M> --- a/sys/kern/uipc_socket.c > M> +++ b/sys/kern/uipc_socket.c > M> @@ -1292,7 +1292,7 @@ solisten_enqueue(struct socket *so, int = connstatus) > M> =20 > M> #if defined(SCTP) || defined(SCTP_SUPPORT) > M> /* > M> - * Socket part of sctp_peeloff(). Detach a new socket from an > M> + * Socket part of sctp_peeloff(). Create a new socket for an > M> * association. The new socket is returned with a reference. > M> * > M> * XXXGL: reduce copy-paste with solisten_clone(). > M> @@ -1304,6 +1304,8 @@ sopeeloff(struct socket *head) > M> =20 > M> VNET_ASSERT(head->so_vnet !=3D NULL, ("%s:%d so_vnet is NULL, = head=3D%p", > M> __func__, __LINE__, head)); > M> + KASSERT(head->so_type =3D=3D SOCK_SEQPACKET, > M> + ("%s: unexpecte so_type: %d", __func__, head->so_type)); > M> so =3D soalloc(head->so_vnet); > M> if (so =3D=3D NULL) { > M> log(LOG_DEBUG, "%s: pcb %p: New socket allocation failure: " > M> @@ -1311,7 +1313,7 @@ sopeeloff(struct socket *head) > M> __func__, head->so_pcb); > M> return (NULL); > M> } > M> - so->so_type =3D head->so_type; > M> + so->so_type =3D SOCK_STREAM; > M> so->so_options =3D head->so_options; > M> so->so_linger =3D head->so_linger; > M> so->so_state =3D (head->so_state & SS_NBIO) | SS_ISCONNECTED; >=20 > This creates a socket where: >=20 > so->so_type !=3D so->so_proto->pr_type. >=20 > I'm not sure this is a good idea. I was actually looking into = removing so_type > at all. What does SCTP idea is about this peel-off thing? If the = resulting > socket is a stream one, shouldn't its so_proto point at = sctp_stream_protosw? Yes, that makes sense. But this is now a generic routine (I think it was an SCTP specific one = in the past), how can I refer to it without using sctp_stream_protosw? Best regards Michael >=20 > --=20 > Gleb Smirnoff