netdev - Re: TCP/IPv4 sending using MSG_ZEROCOPY and closing the socket

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:   Tue, 29 Jan 2019 07:14:16 +0000
From:   mathias_koehrer@...or.de
To:     "Willem de Bruijn" <willemdebruijn.kernel@...il.com>
Cc:     "Network Development" <netdev@...r.kernel.org>,
        "Willem de Bruijn" <willemb@...gle.com>
Subject: Re: TCP/IPv4 sending using MSG_ZEROCOPY and closing the socket

>> Hi all,
>> 
>> I have one question on the behavior of TCP/IPv4 sending using the MSG_ZEROCOPY flag,
>> the kernel version is 4.19.18.
>> 
>> What happens if I close the sending socket immediately after performing a socket
>> send() or sendmsg() call (called with the MSG_ZEROCOPY flag)?
>> I.e. in this situation not all messages have been sent yet, however - as the
>> socket is closed - it is no longer possible to retrieve the completion
>> notification via the error channel.
>> 
>> Is it fine for the user space program to free all outstanding messages after the
>> socket close() has returned?
>> Or is there anything else that has to be considered?
> 
> If closing the socket while user memory is still in transmission, it
> will not be possible to safely reuse the memory, as the process has no
> way of discovering when the kernel has finished transmission.
> 
> Depending on type of memory, there may be workarounds to avoid
> unbound virtual memory growth, such as unmapping the virtual
> address range in the case of mmap()ed data.
> 
> But in general, the right approach is to wait for all completions
> before closing a socket.
> 
> If this takes a long time, say due to the TCP stack hold on to data for
> retransmission in the case a peer does not properly close its side,
> disconnect (connect() AF_UNSPEC) can be used to purge the
> queues and trigger notifications. Again, this is a last resort and
> usually not needed.
Hi Willem!
Thank you for the clarification.
Do you think you could add this to the documentation of MSG_ZEROCOPY?
I think this could be really helpful for all users of the zerocopy feature.

Thanks a lot

Mathias