From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42CD33264EB; Tue, 19 May 2026 14:32:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.146 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779201132; cv=none; b=YU2PiKCs5YGiHRQa9knC9UIobvyp6CF8HO1q3eGaK7TTl9DRT9dEmhPAJsvKZuHY+ck7HBtya9Oh5zihaIaxz+Os3E1JXhbuHfHqtSliEYidtErp+K456j7/Jm06ItVnSKQqk3thnp08wq3KR32mWSKq//m1ntNIKaxIfdeU260= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779201132; c=relaxed/simple; bh=EDZm87HB9wFy0ZnPR+iKkIWaEkEWZHT6UwMzQ7t7+ZY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q4/M0Mi+CmoKDs05SrB0WmJt3Yiz1y/GI0KGRj+UuiyYQlnHX+sDsJ1ip6vliWZcAlhXB7LTBm1MI4ni5vD6WyWblU3NmlYAbyLTV/cul2dc6xEWJBxFfoEDxAhsrwHg9+8QHxAExtTiGewPRYy6Iw+L5QBIFKDHz2mHt2oTAvU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net; spf=pass smtp.mailfrom=queasysnail.net; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b=q8taEtfj; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=DjXhvUzq; arc=none smtp.client-ip=103.168.172.146 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b="q8taEtfj"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="DjXhvUzq" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 48BBFEC010D; Tue, 19 May 2026 10:32:08 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Tue, 19 May 2026 10:32:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queasysnail.net; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1779201128; x= 1779287528; bh=HL5bqItaGufBm3VrudXIILPHtr/6PDyA/V2SB1E5lFM=; b=q 8taEtfjXD3PPm8Mrrys2M0wnX3A+S9Vvm/ykj8nOVFj0z7DjHKTMikCX9twG/ltX kZ25xElDyB7Fd8AOGfa8wGau4GhDy7JMEOY+SiIVQB3IC9kTWxl7RNXxUPV/wcxR 2cdlCB+n/Fmw3bVNP4VX/UYJZhAwWERx/+VtFJfS8NdKI3lpq8zpMVAyLSubWVZw HDVuFT8XIIIuDIotphKjZErMme57tHjOqygzufYZNevr7MIcWvxC+B6tIsz97XJe f3w+aLr1ktfarlC9fYnUpZQgLP97mEUpCqFAzYE4rRtSbsnkf4EyRPvAdQMrF3dP d+QT7I5lrQEQGD+rG2U6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1779201128; x=1779287528; bh=HL5bqItaGufBm3VrudXIILPHtr/6PDyA/V2 SB1E5lFM=; b=DjXhvUzqUdyiFnDl+dJy8LTDzATOOmp2PZKmMiKbE+JMKTMG0dd +OBzLkS51HnYpkOr1o6q4yLwizqwg1jnSG8UGCS896/nCX8ELjw55ejKfwegJR7T 592jsig3INRZeDkpDWnFfTjLR+23iAOMw6dt15ZgTLW8tvX2iKKrmk6OOShDnOzv 12uK+7eYUv7ZS4jcN9WPVEMdOkZHkRORR/cXRNG0pxd+gLsdN8niXlkRh8671s9m zcbxy0iWSpwtjBELEvjTGuCjHCmIoSAIbnIrNEI9NWuXAdRJAnu8oSQVa/798/JI sdnH0toTHOh+EkCai94xDDzD0MjL98OSlsA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddugedvtddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtjeenucfhrhhomhepufgrsghrihhn rgcuffhusghrohgtrgcuoehsugesqhhuvggrshihshhnrghilhdrnhgvtheqnecuggftrf grthhtvghrnhepuefhhfffgfffhfefueeiudegtdefhfekgeetheegheeifffguedvueff fefgudffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshgusehquhgvrghshihsnhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeelpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehmihgthhgrvghlrdgsohhmmhgrrhhithhose hgmhgrihhlrdgtohhmpdhrtghpthhtoheprghnthhonhhiohesohhpvghnvhhpnhdrnhgv thdprhgtphhtthhopegrnhgurhgvfidonhgvthguvghvsehluhhnnhdrtghhpdhrtghpth htohepuggrvhgvmhesuggrvhgvmhhlohhfthdrnhgvthdprhgtphhtthhopegvughumhgr iigvthesghhoohhglhgvrdgtohhmpdhrtghpthhtohepkhhusggrsehkvghrnhgvlhdroh hrghdprhgtphhtthhopehprggsvghnihesrhgvughhrghtrdgtohhmpdhrtghpthhtohep nhgvthguvghvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugi dqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i934648bf:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 May 2026 10:32:07 -0400 (EDT) Date: Tue, 19 May 2026 16:32:05 +0200 From: Sabrina Dubroca To: Michael Bommarito Cc: Antonio Quartulli , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: ovpn: refuse TCP socket layering with an active ULP Message-ID: References: <20260517155645.3882533-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260517155645.3882533-1-michael.bommarito@gmail.com> 2026-05-17, 11:56:45 -0400, Michael Bommarito wrote: > ovpn's TCP transport replaces sk_prot, sk_data_ready, sk_write_space > and sk_socket->ops by direct field writes when a peer is attached, and > restores them by direct field writes when the peer is detached. That > layering scheme is not compatible with a TCP ULP (e.g. kTLS) being > installed on the same socket: ULP setup also captures the current > sk_prot as its lower layer and replaces sk_prot with its own. The two > schemes are not aware of each other and can be combined in either > order on the same fd. It looks like we should make ovpn-tcp a ULP (without requesting userspace to do the setsockopt, since we messed that up a year ago. I thought I had suggested that at some point, but maybe not). That's what it is anyway, and layering ovpn on top of (or underneath) ktls or espintcp makes no sense. It would save us the messy restore hacks in this patch. mptcp calls tcp_set_ulp() from the setup, maybe ovpn can also do that. detach() may be an issue. [...] > @@ -583,6 +610,26 @@ static void ovpn_tcp_close(struct sock *sk, long timeout) > sock = rcu_dereference_sk_user_data(sk); > if (!sock || !sock->peer || !ovpn_peer_hold(sock->peer)) { > rcu_read_unlock(); > + /* No (or no-longer-attached) ovpn state on this socket. > + * That happens when ovpn_tcp_socket_detach() already ran > + * and cleared sk_user_data, but the caller chain still > + * dispatches ->close() on ovpn_tcp_prot. The two cases > + * that exhibit this are: > + * - a TCP ULP layered on top of ovpn whose close hook > + * chains via the captured ctx->sk_proto (which is > + * &ovpn_tcp_prot) after detach has run; > + * - the close-vs-detach race window where sk_user_data > + * has been cleared but sk_prot has not yet been > + * restored. > + * In both cases the TCP layer still owes the peer a > + * graceful close, so chain to the base TCP close. > + */ This is a whole commit message, not a code comment. > +#if IS_ENABLED(CONFIG_IPV6) > + if (sk->sk_family == AF_INET6) > + tcpv6_prot.close(sk, timeout); > + else > +#endif > + tcp_prot.close(sk, timeout); Isn't that a separate problem? (detach racing with close) Or it only appears after the other changes because you removed clearing the CBs? -- Sabrina