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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 12 Aug 2021 17:51:00 +0200
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Bui Quang Minh <minhquangbui99@...il.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, yoshfuji@...ux-ipv6.org,
        dsahern@...nel.org, willemb@...gle.com, pabeni@...hat.com,
        avagin@...il.com, alexander@...alicyn.com,
        lesedorucalin01@...il.com
Subject: Re: [PATCH v2 1/2] udp: UDP socket send queue repair



On 8/12/21 3:46 PM, Bui Quang Minh wrote:
> 
> 
> On 8/11/2021 11:14 PM, Eric Dumazet wrote:
>>
>>
>> On 8/11/21 5:45 PM, Bui Quang Minh wrote:
>>> In this patch, I implement UDP_REPAIR sockoption and a new path in
>>> udp_recvmsg for dumping the corked packet in UDP socket's send queue.
>>>
>>> A userspace program can use recvmsg syscall to get the packet's data and
>>> the msg_name information of the packet. Currently, other related
>>> information in inet_cork that are set in cmsg are not dumped.
>>>
>>> While working on this, I was aware of Lese Doru Calin's patch and got some
>>> ideas from it.
>>
>>
>> What is the use case for this feature, adding a test in UDP fast path ?
> 
> This feature is used to help CRIU to dump CORKed UDP packet in send queue. I'm sorry for being not aware of the performance perspective here.

UDP is not reliable.

I find a bit strange we add so many lines of code
for a feature trying very hard to to drop _one_ packet.

I think a much better changelog would be welcomed.

> 
>> IMO, TCP_REPAIR hijacking standard system calls was a design error,
>> we should have added new system calls.
> 
> You are right that adding new system calls is a better approach. What do you think about adding a new option in getsockopt approach?
> 
> Thanks,
> Quang Minh.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ