netdev - Re: [net-next 2/2] tcp: correct handling of extreme menory squeeze

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 8 Apr 2024 07:01:22 -0400
From: Jon Maloy <jmaloy@...hat.com>
To: Menglong Dong <menglong8.dong@...il.com>,
 Jason Xing <kerneljasonxing@...il.com>, Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
 passt-dev@...st.top, sbrivio@...hat.com, lvivier@...hat.com,
 dgibson@...hat.com, eric.dumazet@...il.com, dongmenglong.8@...edance.com
Subject: Re: [net-next 2/2] tcp: correct handling of extreme menory squeeze



On 2024-04-07 03:51, Menglong Dong wrote:
> On Sun, Apr 7, 2024 at 2:52 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>> On Sun, Apr 7, 2024 at 2:38 AM Eric Dumazet <edumazet@...gle.com> wrote:
[...]
>>>> [5201<->54494]: tcp_recvmsg_locked(<-) returning -11 bytes, window now: 250164, qlen: 0
>>>>
>>>> We can see that although we are adverising a window size of zero,
>>>> tp->rcv_wnd is not updated accordingly. This leads to a discrepancy
>>>> between this side's and the peer's view of the current window size.
>>>> - The peer thinks the window is zero, and stops sending.
> Hi!
>
> In my original logic, the client will send a zero-window
> ack when it drops the skb because it is out of the
> memory. And the peer SHOULD keep retrans the dropped
> packet.
>
> Does the peer do the transmission in this case? The receive
> window of the peer SHOULD recover once the
> retransmission is successful.
The "peer" is this case is our user-space protocol splicer, emulating
the behavior of of the remote end socket.
At a first glance, it looks like it is *not* performing any retransmits
at all when it sees a zero window at the receiver, so this might indeed
be the problem.
I will be out of office today, but I will test this later this week.

///jon

>
>>>> - This side ends up in a cycle where it repeatedly caclulates a new
>>>>    window size it finds too small to advertise.
> Yeah,  the zero-window suppressed the sending of ack in
> __tcp_cleanup_rbuf, which I wasn't aware of.
>
> The ack will recover the receive window of the peer. Does
> it make the peer retrans the dropped data immediately?
> In my opinion, the peer still needs to retrans the dropped
> packet until the retransmission timer timeout. Isn't it?
>
> If it is, maybe we can do the retransmission immediately
> if we are in zero-window from a window-shrink, which can
> make the recovery faster.
>
> [......]
>>> Any particular reason to not cc Menglong Dong ?
>>> (I just did)
>> He is not working at Tencent any more. Let me CC here one more time.
> Thanks for CC the new email of mine, it's very kind of you,
> xing :/
>