From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m16.yeah.net (mail-m16.yeah.net [220.197.32.17]) (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 20C01391E45; Thu, 4 Jun 2026 08:55:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.32.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780563338; cv=none; b=i7FHRck1rVUmA39kZRAarp3SFKJHsfLVaM/0QR8tsdjyodJTqLju0yLivjTdVYIWBCSrCGLLp8YyBFABBmLKlqpEmZTHJVQ7ptbfdb6qjvTaxshYyjpx7XkNmLZVVKEmXDu5gFzuVQ+fn6WNOnxzKGYT54GNgv9XoA1IJdyle2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780563338; c=relaxed/simple; bh=OZhIrREOk5xqsN7sLFlNvuIz95WyJa1sgb9bIzxf8IA=; h=Message-ID:Date:MIME-Version:To:From:Subject:Cc:Content-Type; b=oSo6+MXN601ReX5dT9OI8LcuIz5ER/fG4AfV7rxcHHrLSO+1v1iDnzW+5y+wza9HfxKl9SLus2ceB1ZyC59qs9HSn0TtL9nKQ2Gsz2xFdJdYPoQ1wcH5GQjhYVQc57Ug7sdi7V9nKT+66+FbFLG4EWXLSDiiYYajYZAVV46iWlc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yeah.net; spf=pass smtp.mailfrom=yeah.net; dkim=pass (1024-bit key) header.d=yeah.net header.i=@yeah.net header.b=iI6n0JY4; arc=none smtp.client-ip=220.197.32.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yeah.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yeah.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yeah.net header.i=@yeah.net header.b="iI6n0JY4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yeah.net; s=s110527; h=Message-ID:Date:MIME-Version:To:From:Subject: Content-Type; bh=qBFSoMFwX16MwlmUQDGEuGdAFIZgIayoUg2RKgDD4QQ=; b=iI6n0JY4Qg/6r6y9HbsazA5M1egTUqqmzGqEks6nqdNgBDR69EEGMwX2ENOMKN /qNBbEMA0EosY4UWcsNG8pnDJ06069r8FUmNpmJYP6J19o6mjXovvcgNp7MK7959 LnIQi7bQbwMjUm7CSIR1YjBwr7GzFJrfopqDhndHWMSa8= Received: from [100.70.220.18] (unknown []) by gzsmtp1 (Coremail) with UTF8SMTPA id Mc8vCgDnrbm6NSFq2tqWAQ--.7870S2; Thu, 04 Jun 2026 16:22:19 +0800 (CST) Message-ID: Date: Thu, 4 Jun 2026 16:22:13 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: edumazet@google.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com From: xietangxin Subject: [BUG] TCP connection deadlock under simultaneous bidirectional ICSK_ACK_NOMEM (OOM) Cc: jmaloy@redhat.com, menglong8.dong@gmail.com, kuniyu@google.com, horms@kernel.org, willemb@google.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CM-TRANSID:Mc8vCgDnrbm6NSFq2tqWAQ--.7870S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7tr18KrWDtF4xJrykJryxXwb_yoW8AF1UpF n3Jry3Crs5t3sayr48tw1xG348Jrs8AFnxJr1qvrWxtw45CFsYgry0q3y09r9FkFyDJryq kF92vF1Dtr1kXaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRUUUUUUUUU= X-CM-SenderInfo: x0lh3tpqj0x0o61htxgoqh3/1tbiIRtekmohNbtCXAAA3t Hi all, We have observed a TCP connection deadlock on stable 6.6 under heavy stress testing. 1.Both Peer A and Peer B enter the ICSK_ACK_NOMEM branch in tcp_select_window(). After commit 8c670bdfa58e ("tcp: correct handling of extreme memory squeeze"), Both peers freeze their rcv_nxt and set rcv_wnd = 0. 2.Prior to freezing, both sides had already sent out flight data. Since both sides are dropping incoming data packets due to OOM, rcv_nxt stops advancing, but the peer's seq of subsequent packets continues to grow. 3.When Peer A receives Peer B's Zero Window ACK, the packet's seq is far ahead of Peer A's frozen rcv_nxt. Both peers drop each other's packet, also no Zero Window Probes are triggered because snd_wnd is never updated to 0. Simplified Packet Trace: Assume Peer A's rcv_nxt = 1000, and Peer B's rcv_nxt = 5000 initially. Time Dir Type Seq Ack Win Len Status ------------------------------------------------------------------------ T1: B -> A [PSH, ACK] 1000 5000 3000 100 (A hits OOM, rcv_nxt=1000) T2: B -> A [ACK] 1100 5000 3000 200 (Dropped due to A's OOM) T3: B -> A [PSH, ACK] 1300 5000 3000 200 (Dropped due to A's OOM) T4: A -> B [PSH, ACK] 5000 1000 3000 100 (B hits OOM, rcv_nxt=5000) T5: A -> B [ACK] 5100 1000 3000 200 (Dropped due to B's OOM) T6: A -> B [PSH, ACK] 5300 1000 3000 200 (Dropped due to B's OOM) -- Both sides are now in OOM. B's Seq is 1500; A's Seq is 5500 -- T7: B -> A [ZeroWin] 1500 5000 0 0 (Dropped: Seq 1500 != 1000) T8: A -> B [ZeroWin] 5500 1000 0 0 (Dropped: Seq 5500 != 5000) T9: A -> B [WinUpdate] 5500 1000 20 0 (Dropped: Seq 5500 != 5000) Should we relax the sequence check in tcp_sequence() for zero window ACK? Any feedback or guidance would be greatly appreciated. -- Best regards, Tangxin Xie