From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.14 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793599910; b=T5nrfwoTL0lx0JwyFzqv/NYXQG0hcBU6ekzRsCeAjezzc9fK//iwcKl1Yt4Xg4XcxNhI RVslGtE2R5Q1xSDFteA8Fn75awxxM1l0JoTNIO637IXd2BI/1SyMY3XGVT5YChcHB/fGg u53pDuAvVVI7EnXIjCgG7F+CsmBcjj9lzzONJBUiux7ervp6LeYkeUpQrvVaDh/9Tm8jF XukGgVXbpzkhdSJZ/0TKlGgCz/Xjfsbr+cGhsNS8eBs8a2dqIkyY/VHgQF2j/k8WjMco7 USZOoWoJN2m2m7lUYxFJ3b2lLAgscsRpBeNRpNlcPGfIRq7RD7dHqZlc3By9ajnW7Ew== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793599910; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=9/+XZluyuQYuL1PPzJIXmb0wYbMN8JEjNGZtTVHdimI=; b=S33FRIHKffLLYCLKT0jggDNmaCz5gQjcYXqe1tgeAJgvVn2X52Gav3bw/q5CO2AxE/2o +BtKSsinAX5iE6g82PgIXWNHbOte4XMxOkjrg+bCCNhxgb+67lv4RZnVeCz0Rar3NsEn+ g8KYUGa7NLXpuA1FF9pU6iRyPh8TgyU1Q9uInup3pXB+V5OUJtdRZ/q7X9tYhtBqNx3aT Y/xUg4h4IqWk0L1KFpgmsQ1kPB+sm8YxnArdxdbYbTCFk/6y6yE/yMFqJBok8qgWCW+UF Ud3LLCGW4YTRTz9/z+v3ZxdkS81Nmtxtp9oRnE/Or7fxPK8MGBAgLVrRWKg2nWVoebA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=NAtJJXle; arc=none smtp.remote-ip=95.215.58.14 Received: from mta1.migadu.com (out-14.mta1.migadu.com [95.215.58.14]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E05C9606A326 for ; Mon, 2 Nov 2026 06:11:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org E05C9606A326 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=NAtJJXle X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=9/+XZluyuQYuL1PPzJIXmb0wYbMN8JEjNGZtTVHdimI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793599907; v=1; x=1794204707; b=NAtJJXlenW+h0I4eC/Y29Ra0n7wrbkvXBzOBWOM7stgSa/poa+4xZCwdeofPTfBuJj+R6nxF 9iX9AChKcJMQlgdhW3WsxTQ8COMW0XIv23CIR78ixFuucpfp3bC+JAYoHtz2fZMaI5mfCZnzX6N EmJNMqXVeozJu9RapD8eY8xo= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 0e361a7862659f90; Mon, 02 Nov 2026 06:11:47 +0000 X-Mizu-Trace-ID: 0e361a7862659f90 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Mon, 2 Nov 2026 14:11:43 +0800 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] tcp: initialize send sequence numbers before deferring TFO To: Qingfang Deng , Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Simon Horman , Yuchung Cheng , Wei Wang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20261102035943.9700-1-qingfang.deng@linux.dev> From: Jiayuan Chen In-Reply-To: <20261102035943.9700-1-qingfang.deng@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/2/26 11:59 AM, Qingfang Deng wrote: > TCP_FASTOPEN_CONNECT can return from connect() before tcp_connect_init() > when a cached cookie or cookieless Fast Open allows deferring the SYN. > At this point write_seq contains the initial sequence number, while > snd_una and snd_nxt have not been initialized to that sequence number. > > Consequently, inet_diag and /proc/net/tcp{,6} report the initial > sequence number as the send queue length despite no SYN or payload being > queued. > > Initialize snd_una and snd_nxt to write_seq before marking the > connection as deferred. Both sequence-based queue lengths then remain > zero until the first write starts the connection and runs > tcp_connect_init(). This patch looks good to me. But idiag_wqueue can still go negative on the normal connect path, since the socket is already hashed and diag does not take the socket lock. We always set write_seq first, then init snd_una later:   tcp_v4_connect     WRITE_ONCE(tp->write_seq, st.seq)     tcp_connect       tcp_connect_init         WRITE_ONCE(tp->snd_una, tp->write_seq) Can you try this instead?   r->idiag_wqueue = READ_ONCE(sk->sk_wmem_queued) ?                     READ_ONCE(tp->write_seq) - READ_ONCE(tp->snd_una) : 0;