netdev - Re: [PATCH net-next v2] net: tcp: support to probe tcp receiver OOM

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 19 Jul 2023 20:35:39 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: ncardwell@...gle.com,
 davem@...emloft.net,
 kuba@...nel.org,
 pabeni@...hat.com,
 corbet@....net,
 dsahern@...nel.org,
 kuniyu@...zon.com,
 morleyd@...gle.com,
 imagedong@...cent.com,
 mfreemon@...udflare.com,
 mubashirq@...gle.com,
 netdev@...r.kernel.org,
 linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net: tcp: support to probe tcp receiver OOM



> On Jul 18, 2023, at 00:46, Eric Dumazet <edumazet@...gle.com> wrote:
> 
> On Thu, Jul 13, 2023 at 1:24 PM <menglong8.dong@...il.com> wrote:
>> 
>> From: Menglong Dong <imagedong@...cent.com>
>> 
>> For now, skb will be dropped directly if rmem schedule fails, which means
>> tcp_try_rmem_schedule() returns an error. This can happen on following
>> cases:
>> 
>> 1. The total memory allocated for TCP protocol is up to tcp_mem[2], and
>>   the receive queue of the tcp socket is not empty.
>> 2. The receive buffer of the tcp socket is full, which can happen on small
>>   packet cases.
>> 
>> If the user hangs and doesn't take away the packet in the receive queue
>> with recv() or read() for a long time, the sender will keep
>> retransmitting until timeout, and the tcp connection will break.
>> 
>> In order to handle such case, we introduce the tcp protocol OOM detection
>> in following steps, as Neal Cardwell suggested:
>> 
> 
> For the record, I dislike this patch. I am not sure what Neal had in mind.
> 
> I suggested instead to send an ACK RWIN 0, whenever we were under
> extreme memory pressure,
> and we only could queue one skb in the receive queue.
> 
> For details, look at the points we call sk_forced_mem_schedule().
> This would be a matter of refactoring code around it, in tcp_data_queue()
> 
> The patch would be much simpler. Nothing changed at the sender side :/

I think you are right. I misunderstood the code in tcp_retransmit_timer().
It seems that it already handle the window shrink case properly.

Let me do more testing first.

Thanks!
Menglong Dong