linux-kernel - Re: [PATCH net-next 1/1] Enter smc_tx_wait when the tx length exceeds the available space

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]

Message-ID: <11f8088f-7605-432b-b90b-f8d16c145565@huawei.com>
Date: Fri, 27 Dec 2024 15:53:54 +0800
From: Li Qiang <liqiang64@...wei.com>
To: Wen Gu <guwen@...ux.alibaba.com>, <wenjia@...ux.ibm.com>,
	<jaka@...ux.ibm.com>, <alibuda@...ux.alibaba.com>, <tonylu@...ux.alibaba.com>
CC: <linux-s390@...r.kernel.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <luanjianhai@...wei.com>,
	<zhangxuzhou4@...wei.com>, <dengguangxing@...wei.com>, <gaochao24@...wei.com>
Subject: Re: [PATCH net-next 1/1] Enter smc_tx_wait when the tx length exceeds
 the available space



在 2024/12/26 21:20, Wen Gu 写道:
> 
> 
> On 2024/12/26 20:22, liqiang wrote:
>> The variable send_done records the number of bytes that have been
>> successfully sent in the context of the code. It is more reasonable
>> to rename it to sent_bytes here.
>>
>> Another modification point is that if the ring buf is full after
>> sendmsg has sent part of the data, the current code will return
>> directly without entering smc_tx_wait, so the judgment of send_done
>> in front of smc_tx_wait is removed.
>>
>> Signed-off-by: liqiang <liqiang64@...wei.com>
>> ---
> 
> Hi liqiang,
> 
> I think this discussion thread[1] can help you understand why this is the case.
> The current design is to avoid the stalled connection problem.

Yes, I read that discussion and the problem does exist. So we should correctly handle
fewer bytes sent than expected in user space (like netperf).

However, according to my verification, in the TCP network or loopback (without smc),
after increasing the memory sent by the client at one time to a large enough size,
a connection deadlock seems to occur. SMC processing will not be stuck due to the
expansion of the sending memory.But when the socket is blocking and sends messages,
its behavior is different from TCP socket.

> 
> Some other small points: issues should be posted to 'net' tree instead of 'net-next'
> tree[2], and currently net-next is closed[3].

Thank you for pointing out the problem, I learned from it.

> 
> [1] https://lore.kernel.org/netdev/20211027085208.16048-2-tonylu@linux.alibaba.com/
> [2] https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
> [3] https://patchwork.hopto.org/net-next.html
> 
> Regards.
> 


-- 
Cheers,
Li Qiang