From: Menglong Dong <menglong.dong@linux.dev>
To: xietangxin <xietangxin@yeah.net>
Cc: edumazet@google.com, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, 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,
linux-stable@vger.kernel.org
Subject: Re: [BUG] TCP connection deadlock under simultaneous bidirectional ICSK_ACK_NOMEM (OOM)
Date: Mon, 08 Jun 2026 19:55:11 +0800 [thread overview]
Message-ID: <g7DvITFWSiW9AoI49uyghw@linux.dev> (raw)
In-Reply-To: <b8a3b4eb-b75d-4cbd-ac1c-9b0a606a932a@yeah.net>
On 2026/6/4 16:22 xietangxin <xietangxin@yeah.net> write:
> 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.
>
Hi,
The problem you addressed is already fixed in this commit:
0e24d17bd966 ("tcp: implement RFC 7323 window retraction receiver requirements"),
which hasn't been picked to the 6.6 branch.
That patch doesn't have the Fix tag, so I'm not sure if it will be picked
to the 6.6 branch. Just CC the linux-stable :)
Thanks!
Menglong Dong
>
> 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
>
>
>
prev parent reply other threads:[~2026-06-08 11:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 8:22 [BUG] TCP connection deadlock under simultaneous bidirectional ICSK_ACK_NOMEM (OOM) xietangxin
2026-06-08 11:55 ` Menglong Dong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=g7DvITFWSiW9AoI49uyghw@linux.dev \
--to=menglong.dong@linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jmaloy@redhat.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stable@vger.kernel.org \
--cc=menglong8.dong@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=xietangxin@yeah.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox